[Online Pubs 0001629]: Shell vs. read(2) errors on the script
The following issue has been set as RELATED TO issue 367. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:Online Pubs Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: URL:unsure which applies Section:unsure which applies == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-01-30 16:45 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 ==
[1003.1(2008)/Issue 7 0000367]: interaction between readonly, export, getopts, and read
The following issue has been set as RELATED TO issue 0001629. == https://austingroupbugs.net/view.php?id=367 == Reported By:eblake Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 367 Category: Shell and Utilities Type: Omission Severity: Objection Priority: normal Status: Applied Name: Eric Blake Organization: Red Hat User Reference: ebb.readonly Section:readonly Page Number:2352 Line Number:74359 Interp Status: Approved Final Accepted Text:See https://austingroupbugs.net/view.php?id=367#c675 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2011-01-06 23:30 UTC Last Modified: 2020-02-14 15:16 UTC == Summary:interaction between readonly, export, getopts, and read == Relationships ID Summary -- related to 0001629 Shell vs. read(2) errors on the script == Issue History Date ModifiedUsername FieldChange == 2011-01-06 23:30 eblake New Issue 2011-01-06 23:30 eblake Status New => Under Review 2011-01-06 23:30 eblake Assigned To => ajosey 2011-01-06 23:30 eblake Name => Eric Blake 2011-01-06 23:30 eblake Organization => Red Hat 2011-01-06 23:30 eblake User Reference=> ebb.readonly 2011-01-06 23:30 eblake Section => readonly 2011-01-06 23:30 eblake Page Number => 2352 2011-01-06 23:30 eblake Line Number => 74359 2011-01-06 23:30 eblake Interp Status => --- 2011-01-07 00:26 eblake Note Added: 645 2011-01-07 17:15 geoffclare Note Added: 646 2011-02-10 16:05 eblake Note Added: 673 2011-02-17 17:04 eblake Note Edited: 673 2011-02-17 17:10 eblake Note Edited: 673 2011-02-17 17:14 Don Cragun Note Added: 675 2011-02-17 17:15 Don Cragun Interp Status--- => Pending 2011-02-17 17:15 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=367#c675 2011-02-17 17:15 Don Cragun Status Under Review => Interpretation Required 2011-02-17 17:15 Don Cragun Resolution Open => Accepted As Marked 2011-02-17 17:16 Don Cragun Tag Attached: issue8 2011-03-15 14:45 ajosey Interp StatusPending => Proposed 2011-03-15 14:45 ajosey Note Added: 703 2011-04-26 15:10 ajosey Interp StatusProposed => Approved 2011-04-26 15:10 ajosey Note Added: 766 2020-02-14 15:16 geoffclare Status Interpretation Required => Applied 2023-01-30 16:45 nick Relationship added related to 0001629 ==
[Issue 8 drafts 0001632]: Tilde expansions with HOME="" or HOME value ending in /
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1632 == Reported By:kre Assigned To: == Project:Issue 8 drafts Issue ID: 1632 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.6.1 Page Number:2319-2320 Line Number:74775-74794 Final Accepted Text: == Date Submitted: 2023-01-31 00:58 UTC Last Modified: 2023-01-31 00:58 UTC == Summary:Tilde expansions with HOME="" or HOME value ending in / Description: The current draft, and earlier versions, this is not a new problem, it could have been filed against any older version - but as 2.6.1 has already been updated for other reasons for Issue 8, it seemed sensible to use its most recent draft, don't specify what should happen if HOME="" or if the value of HOME ends in a '/' - including particularly, the case of HOME=/ The case of HOME=/ is perhaps most interesting, as if the text is treated literally, which almost all shells do, the result of expanding ~/foo in such a case is //foo which is an unspecified pathname (as I understand it). A recent ksh93 produces /foo from this case, but that's the only shell I can find which does (amusingly, for the case of HOME=/dir/ that version of ksh93 produces /dir//foo for ~/foo whereas an older one produces //foo for HOME=/ and /dir/foo for the HOME=/dir/ case).. mksh also makes /dir/foo in the HOME=/dir/ case and //foo in the HOME= case, most other shells simply do as the standard says, and replace the tilde prefix (just '~' here) with the value of HOME, which results in the // in both cases. This leads to the desire to use HOME="" instead of HOME=/ in the case where the home directory is intended to be the root directory, which results in ~/foo expanding to /foo in almost all shells (the now quite old FreeBSD shell I use to test with doesn't expand ~ at all when $HOME is an empty string, but that is. or quite likely was, clearly a bug, so I assume it has been fixed sometime in the past several years). However, despite the language of the standard: The pathname resulting from tilde expansion shall be treated as if quoted to prevent it being altered by field splitting and pathname expansion. most shells expand a word which is just ~ to nothing if HOME='' rather than (effectively) to "" which that sentence seems to require. Only bash, the NetBSD shell, and the older version of ksh93 made "". (Again, the FreeBSD shell just produces ~ here, for the same reason as above). This all needs to be cleaned up. Desired Action: I'd suggest requiring that if a pathname resulting from a tilde espansion (a term which really ought be better defined - I assume that in ~/foo where HOME=/dir that the pathname intended is "/dir" not "/dir/foo" otherwise ~/*.c would never be able to work) ends in a / that if a / occurs as the next character of the word containing the tilde expansion be omitted from the result - as that produces better results overall (despite it going to require changes in most shells, including the one I maintain). I'd also suggest being more explicit either than when HOME='' ~ expands to "" or nothing (it makes no difference if there is more to the word). For this, I'd prefer "" (for both the obvious reason, and because it is more consistemt with both the current wording, and useful behaviour). == Issue History Date ModifiedUsername FieldChange == 2023-01-31 00:58 kreNew Issue 2023-01-31 00:58 kreName => Robert Elz 2023-01-31 00:58 kreSection => XCU 2.6.1 2023-01-31 00:58 krePage Number => 2319-2320 2023-01-31 00:58 kreLine Number => 74775-74794 ==
[Online Pubs 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:Online Pubs Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: URL:unsure which applies Section:unsure which applies == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-02 15:51 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006142) chet_ramey (reporter) - 2023-02-02 15:51 https://www.austingroupbugs.net/view.php?id=1629#c6142 -- I see that the minutes of the 30 January meeting begin to address this. The summary says that this is "partially handled by ... https://www.austingroupbugs.net/view.php?id=367;. I assume that means for errors during the `read' builtin. It's far from clear that an EIO (or ESTALE, or whatever) error while reading a script is meant to be one of the "an error other than ...," but if it is, it's best to state that explicitly instead of hiding behind the "including, but not limited to" language. Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 2023-02-02 15:51 chet_ramey Note Added: 0006142 ==
