[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Applied Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1629#c6210 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-06-13 11:08 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... related to 0001490 warn app writers about flush errors not... related to 0001617 what tsort should do with cycles? == -- (0006329) geoffclare (manager) - 2023-06-13 11:08 https://austingroupbugs.net/view.php?id=1629#c6329 -- When applying this bug I noticed that the tsort FUTURE DIRECTIONS section needed to be changed in line with the change to the RATIONALE section, and I have made that change. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 2023-03-10 14:52 kreNote Added: 0006200 2023-03-10 21:33 chet_ramey Note Added: 0006201 2023-03-20 15:48 eblake Relationship added related to 0001490 2023-03-20 16:21 geoffclare Note Added: 0006210
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
The following issue has been set as RELATED TO issue 0001617. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1629#c6210 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-20 16:28 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... related to 0001490 warn app writers about flush errors not... related to 0001617 what tsort should do with cycles? == 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 2023-03-10 14:52 kreNote Added: 0006200 2023-03-10 21:33 chet_ramey Note Added: 0006201 2023-03-20 15:48 eblake Relationship added related to 0001490 2023-03-20 16:21 geoffclare Note Added: 0006210 2023-03-20 16:23 geoffclare Page Number => (page or range of pages) 2023-03-20 16:23 geoffclare Line Number => (Line or range of lines) 2023-03-20 16:23 geoffclare Interp Status => --- 2023-03-20 16:23 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1629#c6210 2023-03-20 16:23 geoffclare Stat
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1629#c6210 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-20 16:23 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... related to 0001490 warn app writers about flush errors not... == 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 2023-03-10 14:52 kreNote Added: 0006200 2023-03-10 21:33 chet_ramey Note Added: 0006201 2023-03-20 15:48 eblake Relationship added related to 0001490 2023-03-20 16:21 geoffclare Note Added: 0006210 2023-03-20 16:23 geoffclare Page Number => (page or range of pages) 2023-03-20 16:23 geoffclare Line Number => (Line or range of lines) 2023-03-20 16:23 geoffclare Interp Status => --- 2023-03-20 16:23 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1629#c6210 2023-03-20 16:23 geoffclare Status New => Resolved 2023-03-20 16:23 geoffclare Resolution
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-20 16:21 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... related to 0001490 warn app writers about flush errors not... == -- (0006210) geoffclare (manager) - 2023-03-20 16:21 https://austingroupbugs.net/view.php?id=1629#c6210 -- Add a row (D2.1 p2330) to the table in 2.8.1 Consequences of Shell Errors: Unrecoverable read error when reading commands | shall exit *4 | shall exit *4 | yes and add a new note after the table: 4. If an unrecoverable read error occurs when reading commands, other than from the file operand of the dot special built-in, the shell shall execute no further commands (including any already successfully read but not yet executed) other than any specified in a previously defined EXIT trap action. An unrecoverable read error while reading from the file operand of the dot special built-in shall be treated as a special built-in utility error. Change P3155, L107009-107011 in the exit status section of the sh utility from: 1-125A non-interactive shell detected an error other than command_file not found or executable, including but not limited to syntax, redirection, or variable assignment errors. to: 1-125A non-interactive shell detected an error other than command_file not found, command_file not executable, or an unrecoverable read error while reading commands (except from the file operand of the dot special built-in); including but not limited to syntax, redirection, or variable assignment errors. Add to the exit status section of the sh utility on P3155 after L107014: 128An unrecoverable read error was detected while reading commands, except from the file operand of the dot special built-in. On D2.1 page 358 line 12462 section (RATIONALE), change: Exit statuses of 126, 127, and greater than 128 are ambiguous in certain circumstances because they have special meanings in the shell (see [xref to XCU 2.8.2]). to: Exit statuses of 126 and greater are ambiguous in certain circumstances because they have special meanings in the shell (see [xref to XCU 2.8.2] and the EXIT STATUS section of [xref to XCU sh]). On D2.1 page 359 line 12469 section (RATIONALE), delete: The value 128 is disallowed for simplicity, making the allowed values 1 to 125 inclusive rather than 1 to 125 inclusive and 128. After D2.1 page 531 line 18867 section _Exit() (APPLICATION USAGE), add a new paragraph: Exit statuses of 126 and greater are ambiguous in certain circumstances because they have special meanings in the shell (see [xref to XCU 2.8.2] and the EXIT STATUS section of [xref to XCU sh]). After D2.1 page 789 line 27009 section exit() (APPLICATION USAGE), add a new paragraph (after applying bug 1490): See also _Exit(). On D2.1 page 2370 line 76769 section exit (RATIONALE), change: As explained in other sections, certain exit status values have been reserved for special uses and should be used by applications only for those purposes: 126 A file to be executed was found, but it was not an executable utility. 127 A utility to be executed was not found. >128 A command was interrupted by a signal. to: As explained in other sections, certain exit status values have been reserved for special uses and should be used by applications only for those purposes: 126 A file to be executed was found, but it was not an exe
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
The following issue has been set as RELATED TO issue 0001490. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-20 15:48 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... related to 0001490 warn app writers about flush errors not... == 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 2023-03-10 14:52 kreNote Added: 0006200 2023-03-10 21:33 chet_ramey Note Added: 0006201 2023-03-20 15:48 eblake Relationship added related to 0001490 ==
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 15/03/2023 00:17, Chet Ramey wrote: On 3/14/23 4:58 PM, Harald van Dijk wrote: On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. Isn't it? The mode bash gets into when invoked as sh is described in the manpage (looking at the 5.2.15 manpage) as: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read. The mode bash gets into when POSIXLY_CORRECT is set, the mode that can also be obtained with --posix, is described in the manpage as: When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. Right. When you force posix mode immediately, as I said above, bash won't read the startup files. A login shell named sh or -sh reads the historical startup fles, then enters posix mode. We are clear on how bash behaves, I believe. What is not clear to me is how I should have worded my message so that you would not have taken issue with it. As far as I can tell, you are saying the same thing I was. I wrote that bash appears to disables the reading of .profile in POSIX mode entirely. It does. I do not see any contradiction between that and what you wrote: while a clarification that this does not apply to bash being invoked as sh or -sh is useful, I made no comment about what happens when bash is invoked as sh or -sh. My comment was about POSIX mode, and when invoked as sh or -sh, per the manpage and your own message, the startup file processing happens while bash is still in non-POSIX mode. So what should I have written instead? If I had written bash appears to disable the reading of .profile in POSIX mode (i.e. bash --posix) entirely. would that have been sufficiently clear to avoid this discussion? If so I will keep that in mind. Cheers, Harald van Dijk
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 3/14/23 4:58 PM, Harald van Dijk wrote: On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. Isn't it? The mode bash gets into when invoked as sh is described in the manpage (looking at the 5.2.15 manpage) as: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read. The mode bash gets into when POSIXLY_CORRECT is set, the mode that can also be obtained with --posix, is described in the manpage as: When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. Right. When you force posix mode immediately, as I said above, bash won't read the startup files. A login shell named sh or -sh reads the historical startup fles, then enters posix mode. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. Isn't it? The mode bash gets into when invoked as sh is described in the manpage (looking at the 5.2.15 manpage) as: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read. The mode bash gets into when POSIXLY_CORRECT is set, the mode that can also be obtained with --posix, is described in the manpage as: When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. My wording appears to be consistent with how bash describes itself in its manpage: there is POSIX mode during startup file processing, and POSIX mode after startup file processing. Only the POSIXLY_CORRECT / --posix behaviour causes startup file processing to happen in POSIX mode, and results in the reading of .profile being disabled. But if I am misunderstanding how you intend for the different modes of bash to be referred to, if you can clarify I can take care to be more careful with my wording in the future. Cheers, Harald van Dijk
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 12/03/2023 19:10, Robert Elz wrote:
Date:Fri, 10 Mar 2023 23:40:18 +
From:"Harald van Dijk via austin-group-l at The Open Group"
Message-ID:
| Based on past experiences, I am assuming the e-mail this is a reply to
| was meant to be sent to the list and I am quoting it in full and
| replying on the list for that reason.
Thanks, and yes, it was - my MUA absolutely believes in the one true
meaning of Reply-To (where the author of the message to which the reply
is being sent requests that replies be sent -- to addresses in that field,
and no others). I need to manually override it when I choose to ignore
that request and send to different addresses (which is allowed, but in
general, done only with proper consideration of why). This list always
directs that all replies go only to the author of the message, and never
to the list itself. Irritating...
I know. Even more frustrating is the reasoning we have been given as to
the reasoning for it ("to better handle DMARC email authentication for
messages" -- no, DMARC absolutely does not require that).
| Sourcing arbitrary script fragments and having assurance that they do
| not exit the shell is not reasonable, as the arbitrary script fragment
| could contain an 'exit' command.
Of course, deliberate exits aren't the issue, only accidental ones.
| Beyond shell options and variable assignments not persisting in the
| parent shell, are there any other issues you see with running them in a
| subshell?
The whole point of many . scripts is to alter the shell's environment,
if they were just arbitrary commands, not intended to affect the current
shell, they'd just be sh scripts, and run the normal way. The very act
of using the '.' command more or less means "must run in the current shell).
"(. file)" is silly, "file" would accomplish the same thing (if executable,
otherwise "sh < file" after finding the path to file) in a more obvious way.
This does not result in the same behaviour. (. file) can be used to
inherit unexported shell variables, shell functions, aliases, etc. from
the parent shell that would not be available to an explicitly launched
sh subprocess.
I agree that it is likely that a . script would be sourced in order to
change the current shell environment, but I do not agree that it is the
only legitimate use of it, and I had assumed based on your "without
risking the shell exiting" that you were considering one of those other
uses.
Apart from options and variables, . files often define functions, change
the umask and perhaps ulimit, and may alter the current directory, set exit
(or other) traps, ... anything in fact.
Sure, they are in the same category as options and variables.
As an example, consider what you might put in your .profile or $ENV
file - those are run in more or less the same way as a '.' file (just
without the PATH search to locate the file). XRAT C.2.5.3 says almost
exactly that about ENV.
Indeed. Worth explicitly pointing out here is that they are only used by
interactive shells, so in this comparison, only the behaviour of the '.'
command in interactive shells is relevant.
(Strangely though, even though .profile is
mentioned several times as a place where things can be set, it doesn't
appear in the standard (as something that shells process) at all - which
is kind of odd really, since it is considerably older then ENV, and as best
I can tell, supported by everything. The closest that we get is a mention
in XRAT that "some shells" run it at startup of a login shell. Which are
the other shells? That is, the ones that don't run .profile? And I don't
mean in situations like bash, which prefers .bash_profile if it exists.
bash appears to disables the reading of .profile in POSIX mode entirely.
yash only ever appears to source .yash_profile, it does not fall back to
.profile if no .yash_profile exists.
I doubt that you'd want those scripts run in a subshell environment,
I also doubt that you want the shell to exit if there's an error in
one of them. How would you ever be able to log in (and start a shell)
if it exited before you ever had a chance to run a command? If you can't
log in, because your shell won't start, how would you ever fix the problem?
As best I can tell (I have done very limited testing of this) shells tend
to simply abort processing one of those scripts upon encountering an error
(like a syntax error, etc - not executing "exit" - that should exit) and
just go on to the next step of initialising the shell. They don't just
exit because there's a syntax error - most shells report the error (not all),
but I couldn't find one which exits.
This is indeed a problem. My own testing supports your conclusion,
shells are in agreement that a syntax error here does not result in the
shell terminating, and does result in the remainder of the envfile being
ignored. An inval
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Date:Fri, 10 Mar 2023 23:40:18 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: | Based on past experiences, I am assuming the e-mail this is a reply to | was meant to be sent to the list and I am quoting it in full and | replying on the list for that reason. Thanks, and yes, it was - my MUA absolutely believes in the one true meaning of Reply-To (where the author of the message to which the reply is being sent requests that replies be sent -- to addresses in that field, and no others). I need to manually override it when I choose to ignore that request and send to different addresses (which is allowed, but in general, done only with proper consideration of why). This list always directs that all replies go only to the author of the message, and never to the list itself. Irritating... | Sourcing arbitrary script fragments and having assurance that they do | not exit the shell is not reasonable, as the arbitrary script fragment | could contain an 'exit' command. Of course, deliberate exits aren't the issue, only accidental ones. | Beyond shell options and variable assignments not persisting in the | parent shell, are there any other issues you see with running them in a | subshell? The whole point of many . scripts is to alter the shell's environment, if they were just arbitrary commands, not intended to affect the current shell, they'd just be sh scripts, and run the normal way. The very act of using the '.' command more or less means "must run in the current shell). "(. file)" is silly, "file" would accomplish the same thing (if executable, otherwise "sh < file" after finding the path to file) in a more obvious way. Apart from options and variables, . files often define functions, change the umask and perhaps ulimit, and may alter the current directory, set exit (or other) traps, ... anything in fact. As an example, consider what you might put in your .profile or $ENV file - those are run in more or less the same way as a '.' file (just without the PATH search to locate the file). XRAT C.2.5.3 says almost exactly that about ENV. (Strangely though, even though .profile is mentioned several times as a place where things can be set, it doesn't appear in the standard (as something that shells process) at all - which is kind of odd really, since it is considerably older then ENV, and as best I can tell, supported by everything. The closest that we get is a mention in XRAT that "some shells" run it at startup of a login shell. Which are the other shells? That is, the ones that don't run .profile? And I don't mean in situations like bash, which prefers .bash_profile if it exists. I doubt that you'd want those scripts run in a subshell environment, I also doubt that you want the shell to exit if there's an error in one of them. How would you ever be able to log in (and start a shell) if it exited before you ever had a chance to run a command? If you can't log in, because your shell won't start, how would you ever fix the problem? As best I can tell (I have done very limited testing of this) shells tend to simply abort processing one of those scripts upon encountering an error (like a syntax error, etc - not executing "exit" - that should exit) and just go on to the next step of initialising the shell. They don't just exit because there's a syntax error - most shells report the error (not all), but I couldn't find one which exits. | You have left out bash 4 here. For the same reason I didn't include ancient versions of all the other shells either. That's obsolete, not going to change in the future, and has been replaced. [And because I happen not to have a binary of it at the minute - I could make one, I do have sources, just don't really see the need.] | I do not expect bosh to have a large user base (even if it will be wider | than mine), but as I am sure J�rg would have pointed out, the shell has | historical significance in that it is a descendant of the Bourne shell | from which POSIX shell language is also derived. So is/was ksh88, and then ksh93 ... they were just modified more. | (Although I wouldn't be | opposed to a change to POSIX to *allow* something different.) As I hinted in the note in bugid:1629 which spawned this discussion (bugnote:6200) I expect this part might need to move to "may exit" rather than "shall not exit" (away from "shall exit" which it is now, in the cases in question, not all) for a release cycle (or two) - but then again given the number, and popularity, of the shells which already don't exit in these circumstances, perhaps that won't be needed. That should be discussed further. The reason that read errors are different in this regard (at least in the main script, not in . files -- not sure it is possible to have an equivalent to a read error in "eval" - perhaps an EILSEQ (bad char encoding) in the string might count? -- and that
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Based on past experiences, I am assuming the e-mail this is a reply to was meant to be sent to the list and I am quoting it in full and replying on the list for that reason. On 10/03/2023 21:24, Robert Elz wrote: Date:Fri, 10 Mar 2023 18:13:00 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: | Other shells that exit are bosh, yash, and my own. It's both what POSIX | currently requires (contrary to what kre wrote on the bug) That's not how I intended what I wrote to be interpreted, I meant exactly what you said - when I wrote "most shells are doing what shells always have, and what the standard requires", I meant "exiting". I'm glad that that is what you meant. I wrote my mail before reading your mail where you said you tested something different, so when I read that you wrote that what most shells are doing is what the standard requires, it could only be interpreted to mean the opposite of what you intended. But as I wrote in my previous message, I was actually testing "command eval" rather than "command ." which I would normally expect to work about the same way in this regard, but it turns out that not shells all do. Further, and subsequent to when I sent that last message, I went and looked at my tests again - the way I do these is by (for tests like this one) composing a command line as input to one shell (each has its own xterm in my shell testing root window page - they're all tiled), then pasting it into the windows for all the others - then I can see the results from all of them, at the same time, and easily compare what happened (the command always starts $SHELL kind of like the example Geoff showed, except I do not quote that, because sometimes SHELL needs to be "bash -o posix" or similar, and I want that field split, not treated as a quoted word. For this, I tested both without, and with, "command" present ... but it turns out that somehow, for some of the shells, instead of running both tests, I managed to paste the wrong command, and ran the one without "command" twice, without noticing. That even included the NetBSD sh test, which contrary to what I said before, turns out does do the same thing for "." and "eval" in both cases (exit without command, not exit with it) which is what I had expected, before I saw the results of the incorrect test - before I noticed it was incorrect. | and what I think is probably the right thing for shells to do. I don't. I want to be able to source arbitrary script fragments, and eval arbitrary strings (there are no security issues here, the fragments and strings, are all provided by the user running the shell - anything that could be done buried one of those other ways, could simply be done as a command without subterfuge) without risking the shell exiting. Sometimes running them in a subshell works, but only sometimes. Sourcing arbitrary script fragments and having assurance that they do not exit the shell is not reasonable, as the arbitrary script fragment could contain an 'exit' command. In order to be able to do this, a subshell is needed. That will mean that variable assignments etc. do not persist in the parent shell, but that is unavoidable. Either the sourced script affects the parent shell, in which case it can cause the parent shell to exit, or it does not affect the parent shell. Beyond shell options and variable assignments not persisting in the parent shell, are there any other issues you see with running them in a subshell? | Whether bug 1629 should introduce a significant shell consistency issue | is not separate from bug 1629. Perhaps that one, and some new one, yet to be submitted, should be considered together, but resolving 1629 the right way should not be held hostage by other ancient weirdness that might not be so easy to alter. But perhaps after all, it might be - if it is only yash, bosh and your shell not already continuing after "command . file" fails because of a syntax error, then those might not matter, and those, plus, I think, mksh and ancient pdksh (and consequently, probably ksh88 as well) for "command eval 'gibberish<;)'" failing the same way then I'd guess mksh can get changed, and the others also no longer really matter. You have left out bash 4 here. For 'command eval', that version behaves the same way as for 'command .' in that it causes the shell to exit on syntax errors. | Bug 1629 started as trying to see what | shell authors are willing to implement. No, it started because read errors were not being handled in a rational way. A proposed solution depended upon what shell authors are willing to implement. True, I should have said "the discussion on bug 1629 started" rather than "bug 1629 started". | and I know bosh sadly isn't going to see an update anyway, Really? I thought some group of people had taken over Schilling's stuff. Whether they consider bosh worth continuing wi
[1003.1(2016/18)/Issue7+TC2 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:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 21:33 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006201) chet_ramey (reporter) - 2023-03-10 21:33 https://www.austingroupbugs.net/view.php?id=1629#c6201 -- I'm going to change the bash behavior to exit immediately with status 128 on read errors while reading commands from a script. I'm going to hold off changing any other behavior. Bash already reads an entire `.' file before parsing and executing any commands in it, so that's not going to be a problem. I'd like to see the behavior of `command .' and `command eval' standardized so shells don't exit if the builtin fails, even with a read error, but I'm willing to have the discussion. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 2023-03-10 14:52 kreNote Added: 0006200 2023-03-10 21:33 chet_ramey Note Added: 0006201 ==
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Date:Fri, 10 Mar 2023 18:13:00 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: | Other shells that exit are bosh, yash, and my own. It's both what POSIX | currently requires (contrary to what kre wrote on the bug) That's not how I intended what I wrote to be interpreted, I meant exactly what you said - when I wrote "most shells are doing what shells always have, and what the standard requires", I meant "exiting". But as I wrote in my previous message, I was actually testing "command eval" rather than "command ." which I would normally expect to work about the same way in this regard, but it turns out that not shells all do. Further, and subsequent to when I sent that last message, I went and looked at my tests again - the way I do these is by (for tests like this one) composing a command line as input to one shell (each has its own xterm in my shell testing root window page - they're all tiled), then pasting it into the windows for all the others - then I can see the results from all of them, at the same time, and easily compare what happened (the command always starts $SHELL kind of like the example Geoff showed, except I do not quote that, because sometimes SHELL needs to be "bash -o posix" or similar, and I want that field split, not treated as a quoted word. For this, I tested both without, and with, "command" present ... but it turns out that somehow, for some of the shells, instead of running both tests, I managed to paste the wrong command, and ran the one without "command" twice, without noticing. That even included the NetBSD sh test, which contrary to what I said before, turns out does do the same thing for "." and "eval" in both cases (exit without command, not exit with it) which is what I had expected, before I saw the results of the incorrect test - before I noticed it was incorrect. | and what I think is probably the right thing for shells to do. I don't. I want to be able to source arbitrary script fragments, and eval arbitrary strings (there are no security issues here, the fragments and strings, are all provided by the user running the shell - anything that could be done buried one of those other ways, could simply be done as a command without subterfuge) without risking the shell exiting. Sometimes running them in a subshell works, but only sometimes. | Whether bug 1629 should introduce a significant shell consistency issue | is not separate from bug 1629. Perhaps that one, and some new one, yet to be submitted, should be considered together, but resolving 1629 the right way should not be held hostage by other ancient weirdness that might not be so easy to alter. But perhaps after all, it might be - if it is only yash, bosh and your shell not already continuing after "command . file" fails because of a syntax error, then those might not matter, and those, plus, I think, mksh and ancient pdksh (and consequently, probably ksh88 as well) for "command eval 'gibberish<;)'" failing the same way then I'd guess mksh can get changed, and the others also no longer really matter. | Bug 1629 started as trying to see what | shell authors are willing to implement. No, it started because read errors were not being handled in a rational way. A proposed solution depended upon what shell authors are willing to implement. | and I know bosh sadly isn't going to see an update anyway, Really? I thought some group of people had taken over Schilling's stuff. Whether they consider bosh worth continuing with I am not sure (it still has more important issues than this remaining in it, and I don't believe is used much, if at all). | but I would hope that authors | of the other shells also have the good sense to implement something that | makes sense to them and keep it internally consistent, There is so much in the shell already which is not internally consistent, that one more thing (particularly in an area rarely seen) would hardly be noticed, but I very much doubt that there will not be at least an attempt to alter the "what happens when there's an error which is "shall exit" detected when running a special built-in as a sub-command of "command". Syntax errors aren't the only one, command eval 'shift 0 >/' is another (redirection errors are also "shall exit" when used with a special built-in as is being done here). I expect that will probably succeed, even if we all need to make some more changes to almost never encountered parts of the shell, and most probably it won't be "we all" in any case. kre
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 10/03/2023 17:12, Geoff Clare via austin-group-l at The Open Group wrote: -- (0006200) kre (reporter) - 2023-03-10 14:52 https://www.austingroupbugs.net/view.php?id=1629#c6200 -- Re https://www.austingroupbugs.net/view.php?id=1629#c6197 https://www.austingroupbugs.net/view.php?id=1629#c6198 https://www.austingroupbugs.net/view.php?id=1629#c6199 : I agree it is probably a problem that shells exit on syntax errors after "command ." (also "command eval") but it is a problem in the sense that it would be better if that isn't what happened - and it isn't just "some shells" that exit, it is most of them. None of the shells I tried exited. I used a file containing: foo < and ran: "$shell" -c 'command . ./file ; echo $?' All of bash, ksh88, ksh93, dash and mksh reported the syntax error and then executed the echo command (which output a non-zero number). For bash, it depends on the version. Version 4 will exit. Other shells that exit are bosh, yash, and my own. It's both what POSIX currently requires (contrary to what kre wrote on the bug) and what I think is probably the right thing for shells to do. In any case, this isn't a problem with the proposed resolution of this issue (read error behaviour) - a new bug needs to be filed and processed to get the behaviour of "command ." and "command eval" altered to be "not exit" (and for this, it may need to start out just being "may exit" rather than "shall not exit" with a future directions indicating that the stronger form will apply in a later version. I agree this should be handled as a separate issue, hence my replying by email instead of a note in the bug. Whether bug 1629 should introduce a significant shell consistency issue is not separate from bug 1629. Bug 1629 started as trying to see what shell authors are willing to implement. In that case, let me be clear, as it stands this is not something I am going to implement as written. I know you have no reason to care what I do in my shell, and I know bosh sadly isn't going to see an update anyway, but I would hope that authors of the other shells also have the good sense to implement something that makes sense to them and keep it internally consistent, whether that is by ignoring what 1629 specifies, or by ignoring what is required for syntax errors. There are more issues that make me doubt this is going to be implemented as written in other shells too, but that's for the other authors to raise. Cheers, Harald van Dijk
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Date:Fri, 10 Mar 2023 17:12:50 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: | All of bash, ksh88, ksh93, dash and mksh reported the syntax error and | then executed the echo command (which output a non-zero number). yash and bosh don't, they simply exit. But you caught me ... the tests I did yesterday were of "command eval" which I assumed would be treated the same (I see no reason why there should be a difference), but apparently isn't in many shells (including the NetBSD one). kre
Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
> -- > (0006200) kre (reporter) - 2023-03-10 14:52 > https://www.austingroupbugs.net/view.php?id=1629#c6200 > -- > Re https://www.austingroupbugs.net/view.php?id=1629#c6197 > https://www.austingroupbugs.net/view.php?id=1629#c6198 > https://www.austingroupbugs.net/view.php?id=1629#c6199 : > > I agree it is probably a problem that shells exit on syntax errors after > "command ." (also "command eval") but it is a problem in the sense that > it would be better if that isn't what happened - and it isn't just "some > shells" that exit, it is most of them. None of the shells I tried exited. I used a file containing: foo < and ran: "$shell" -c 'command . ./file ; echo $?' All of bash, ksh88, ksh93, dash and mksh reported the syntax error and then executed the echo command (which output a non-zero number). > In any case, this isn't a problem with the proposed resolution of this > issue (read error behaviour) - a new bug needs to be filed and processed > to get the behaviour of "command ." and "command eval" altered to be > "not exit" (and for this, it may need to start out just being "may exit" > rather than "shall not exit" with a future directions indicating that the > stronger form will apply in a later version. I agree this should be handled as a separate issue, hence my replying by email instead of a note in the bug. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016/18)/Issue7+TC2 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:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 14:52 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006200) kre (reporter) - 2023-03-10 14:52 https://www.austingroupbugs.net/view.php?id=1629#c6200 -- Re https://www.austingroupbugs.net/view.php?id=1629#c6197 https://www.austingroupbugs.net/view.php?id=1629#c6198 https://www.austingroupbugs.net/view.php?id=1629#c6199 : I agree it is probably a problem that shells exit on syntax errors after "command ." (also "command eval") but it is a problem in the sense that it would be better if that isn't what happened - and it isn't just "some shells" that exit, it is most of them. I also agree it would be better for syntax errors and read errors to be treated the same for this. That is where we get a problem - read error requirements are new, and we can more or less do what we like, since everyone has more or less agreed that "treat it like EOF" which just about everyone did is not the right thing to do, and shells are going to have to change anyway. But for syntax errors, most shells are doing what shells always have, and what the standard requires - there even might be applications depending upon this behaviour (though I don't think I have seen many "command eval" and even less, if any "command ." in real scripts - and bash and zsh don't bother exiting (bash in non-posix mode anyway) even without "command" so probably there aren't applications that will care, but we cannot know. In any case, this isn't a problem with the proposed resolution of this issue (read error behaviour) - a new bug needs to be filed and processed to get the behaviour of "command ." and "command eval" altered to be "not exit" (and for this, it may need to start out just being "may exit" rather than "shall not exit" with a future directions indicating that the stronger form will apply in a later version. Incidentally, it appears there is no way to prevent a shell from exiting on a syntax error in a trap command string (action) - those are run "in a matter equivalent to eval action" which must include in the interpretation, as if by a special builtin, so if there is a failure to parse the action, the shell is currently required to exit (non-interactive shells) which is probably sub-optimal. (I haven't yet tested to see what shells actually do for this). 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project O
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 10:57 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006199) hvd (reporter) - 2023-03-10 10:57 https://austingroupbugs.net/view.php?id=1629#c6199 -- > True, and this is a defect for the syntax error case, as existing shells do not exit. Some existing shells do not exit. Others do. > It requires 128, not 126. Apologies, I noticed the change to require a specific exit status and not that it had been changed from 126. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 ==
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 09:20 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006198) geoffclare (manager) - 2023-03-10 09:20 https://austingroupbugs.net/view.php?id=1629#c6198 -- > The new proposed resolution would require 'command . /some/file' to exit the shell on syntax errors, but would also require to not exit the shell on read errors. True, and this is a defect for the syntax error case, as existing shells do not exit. > The new proposed resolution requires an exit status of 126. It requires 128, not 126. The consensus in the teleconference was to agree with the comments that said 126 would not be appropriate, and also with the comments that said 128 would be a good choice. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 ==
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-09 17:44 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006197) hvd (reporter) - 2023-03-09 17:44 https://austingroupbugs.net/view.php?id=1629#c6197 -- The new proposed resolution would require 'command . /some/file' to exit the shell on syntax errors, but would also require to not exit the shell on read errors. This is inappropriate. The new proposed resolution requires an exit status of 126. This is also inappropriate. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 ==
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-09 17:29 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006196) geoffclare (manager) - 2023-03-09 17:29 https://austingroupbugs.net/view.php?id=1629#c6196 -- New proposed resolution... Add a row (D2.1 p2330) to the table in 2.8.1 Consequences of Shell Errors: Read error when reading commands | shall exit *4 | shall exit *4 | yes and add a new note after the table: 4. If a read error occurs when reading commands, other than from the file operand of the dot special built-in, the shell shall execute no further commands (including any already successfully read but not yet executed) other than any specified in a previously defined EXIT trap action. A read error while reading from the file operand of the dot special built-in shall be treated as a special built-in utility error. Add to the exit status section of the sh utility on P3155 after L107008: 128A read error was detected while reading commands, except from the file operand of the dot special built-in. Change P3155, L107009-107011 in the exit status section of the sh utility from: 1-125A non-interactive shell detected an error other than command_file not found or executable, including but not limited to syntax, redirection, or variable assignment errors. to: 1-125A non-interactive shell detected an error other than command_file not found, command_file not executable, or a read error while reading commands (except from the file operand of the dot special built-in); including but not limited to syntax, redirection, or variable assignment errors. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-06 19:07 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006195) hvd (reporter) - 2023-03-06 19:07 https://austingroupbugs.net/view.php?id=1629#c6195 -- On the possible special handling for 'command .': it makes sense that this would be treated the same as a syntax error in a file read by the command, but shells are not in agreement on what to do there and POSIX is less clear than it could be. echo \< >test command . ./test echo still here In a non-interactive shell, what is the expected behaviour? "Consequences of Shell Errors" says that a non-interactive shell shall exit on "Shell language syntax error". The description of the command builtin says "If the command_name is the same as the name of one of the special built-in utilities, the special properties in the enumerated list at the beginning of Special Built-In Utilities shall not occur." Exiting on a syntax error is not one of the special properties in that list, so by my reading, that rule remains in full effect even in 'command .' and the fact that many shells print "still here" contradicts what I believe POSIX requires (without comment on whether POSIX is right to require this). That same reading also applies to the proposed wording in Note: 0006145; a read error encountered during 'command .' should cause the shell to exit. This is a change I would be willing to make. I would not be happy to have these two cases be treated differently without a good reason, but if this is not the intended interpretation, I would also be happy to implement to-be-written alternative wording that would require the shell to survive syntax errors *and* read errors alike in 'command .'. However, in interactive shells, read errors in a '.' should definitely not require the shell to exit, only read errors in the top-level script should have that effect. If a user does e.g. '. /proc/self/mem' (reading from the start of /proc/self/mem will fail with EIO), there is no reason not to allow the user to read more commands, that fd is still perfectly fine. The suggested wording does require the shell to exit in that case. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-05 11:20 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006192) hvd (reporter) - 2023-03-05 11:20 https://austingroupbugs.net/view.php?id=1629#c6192 -- > Status 126 indicates failure to execute. I think that would be a bit misleading as the real problem here is a script read error after execution has successfully commenced. I agree. If existing programs or scripts have any special handling of exit code 126, they would rightly assume that no action has yet taken place and the failed command can safely be retried in another way. For read errors in the middle of a script that already partially executed, that is inappropriate. But we are talking about scripts on unreliable media. They are going to fail unpredictably. They may result in read errors, they may result in bogus reads resulting in syntax errors, they may result in bogus reads resulting in valid scripts that do something other than what is intended. Because of that, scripts cannot meaningfully install handlers for read errors of the top-level script. And because of *that*, personally, I am not seeing a real benefit to requiring a specific exit code, I cannot see that being used in any meaningful way. Shells already do not agree on what exit code to use for syntax errors, for unsupported options, etc. Shells already do not even agree on the exit code for scripts not being found, despite that actually being defined by POSIX. Mandating a particular exit code for this that cannot be meaningfully used, but not for the other ones that can, I see no point to it. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-22 17:39 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006168) McDutchie (reporter) - 2023-02-22 17:39 https://austingroupbugs.net/view.php?id=1629#c6168 -- Re https://austingroupbugs.net/view.php?id=1629#c6158: "Can we not standardise on a code here, if we’re changing things anyway? From the proposal, 126 looks the most palatable to me, so change 1–126 to just 126 (again, if everyone agrees)." Status 126 indicates failure to execute. I think that would be a bit misleading as the real problem here is a script read error after execution has successfully commenced. I think 128 is the best exit status for such panic or fatal error conditions. It is the highest non-signal exit status (signals are > 128), and is not currently specified for anything (regular errors are < 126), leaving it free to signify that something unusual happened that requires urgent attention. A precedent is git, which uses status 128 for fatal errors. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 ==
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-22 17:25 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006167) McDutchie (reporter) - 2023-02-22 17:25 https://austingroupbugs.net/view.php?id=1629#c6167 -- Re 0006145: "[...] so we would like feedback from shell authors to indicate whether they are willing to make changes to follow these new requirements." Absolutely. I will fix this in ksh 93u+m regardless of what POSIX decides, because a failure to read from a script after execution has commenced is a fatal error that warrants throwing a panic. The possible execution of a partial command is one reason for this, but partially executing a script is not better. Either way, an inconsistent state results. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 ==
[1003.1(2016/18)/Issue7+TC2 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:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-21 05:58 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006163) kre (reporter) - 2023-02-21 05:58 https://www.austingroupbugs.net/view.php?id=1629#c6163 -- Rather that trying to deal with what a "partial command" might mean, I'd rather simply say that if exiting, the shell shall not execute any commands not yet already executed, except for the exit trap (if one has already been defined). If the shell is not exiting (for which the only case I can currently imagine is "command . file" in a non-interactive shell, or any "." command in an interactive one) then the exit status should be non-zero (I'm not sure it matters much if we attempt to define 126 for that, or just anything). Note that even an interactive shell "shall exit" if it gets a read error on its standard input, nothing else makes any sense. So, apart from adding something about read errors in the file used for a '.' command, I'd change note 4 (*4) being added in section 2.8.1 to say *4 If a read error occurs, and the shell is to exit, the shell shall execute no further commands, other than any specified in a previously defined EXIT trap action. And for the case of a '.' command failing due to a read error *5 If a read error occurs reading the file specified as the argument to the '.' command, the shell shall execute no commands from that file it has not already executed. The read error is then treated as a failure of the '.' command. Does that make sense to everyone? Is it sufficient? 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 ==
[1003.1(2016/18)/Issue7+TC2 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:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-20 22:47 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006161) mirabilos (reporter) - 2023-02-20 22:47 https://www.austingroupbugs.net/view.php?id=1629#c6161 -- The ‘.’ behaviour definitely needs specifying and testing, yeah. I like your interpretation of not terminating the outer/calling script but allowing it to handle the error. As for “partial commands”… this part is indeed tricky. I’d like for the specification of this to move away from partial commands and also not to partial lines (as in the mail discussion with Chet, Bart and Robert). This would complicate the implementation, at least for cases where the shell can use blocked/buffered reads. Without consideration for lines, I’d implement it in mksh like this, if the read(2) fails, then I just terminate immediately with an error (instead of an EOF). Anything that happened prior to this was executed, anything that would be executed if it were an EOF wouldn’t. Hmm, so maybe partial command is right-ish, except not command but shell-consumable (let’s not add this word to the standard but I’m using it here to brainstorm) (a command is only consumable once terminated, e.g. by ; or newline), but… hmm… … anyway. I would just put it in the place where more input is read. I experimented with this right now, and I can just plug a yyerror() in there (i.e. treating it as a simulated syntax error) and it’ll DTRT (even for dot) although with errorlevel 1 not 126. So this _seems_ to DTRT… 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 ==
[1003.1(2016/18)/Issue7+TC2 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:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-20 21:14 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006160) chet_ramey (reporter) - 2023-02-20 21:14 https://www.austingroupbugs.net/view.php?id=1629#c6160 -- How, if at all, does this affect the behavior of `.'? I assume that this interpretation intends that read errors during execution of `.' are treated as fatal special builtin errors similar to pathname not found. If the shell parses the contents of the file as a program, the shell should handle read errors as it would when reading a shell script and treat them as a fatal error for `.', with the consequences that implies. Is that the intent? Another question is exactly what constitutes a `partial command'. If you have a line that reads echo a; echo b; echo c and you get a read error after the second `;', this isn't exactly a `partial command'. It's a perfectly valid list. Or is this more intended to address partial lines? Getting EOF while parsing a compound command like `while' is already a syntax error, so this doesn't seem to make a difference there. It's mostly lists and pipelines. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 ==
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-18 21:51 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006158) mirabilos (reporter) - 2023-02-18 21:51 https://austingroupbugs.net/view.php?id=1629#c6158 -- I’m okay with the proposal. To clarify, this is for nōn-interactive shells only, and interactive shells treat it as EOF. I think we can go around the “lawmaking” concern by looking at whether “all” shell maintainers agree to make the change, and if so, add it as requirement soon because it’ll be existing practice in all shells in a short while? Can we not standardise on a code here, if we’re changing things anyway? >From the proposal, 126 looks the most palatable to me, so change 1–126 to just 126 (again, if everyone agrees). For the record, I’m very much willing to make this change to mksh. 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 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 ==
