0001427: 2.8.1 does not take into account "command"

Notes
(0005124) kre (reporter) 2020-11-30 19:36 edited on: 2020-11-30 19:37	It might be worth answering the question "what does happen when a shell does not exit after an error which would normally be 'shall exit'?" in the various situations where this can occur. My impression (without a lot of testing for now) is that when the reason the shell does not exit is because it is interactive, the normal behaviour is to abort whatever processing was happening (the entire command/list/program that has been input) and return to the top level, issue PS1, and wait for more from the command input stream. At least that's the case for the top level shell, my impression is that even for interactive shells, when encountering a "shall exit" in a sub-shell environment, that sub-shell exits (I'm not sure if this is specified somewhere, it might be.) On the other hand, when not exiting because "command" has turned a special builtin error into a "not exit" condition, my (so far limited) testing indicates that shells simply continue with whatever follows the "command" command in the normal sequence. That's not at all the same as what happens with an interactive shell where the same special builtin (but without the "command" command being used) fails for whatever reason it is failing. An easy test setup for this is to use the special builtin "eval" as that one is trivially easy to make fail. The two scenarios are, in an interactive shell eval 'nonsense ><; foobar'; printf 'continued\n' and in any shell command eval 'nonsense ><; foobar'; printf 'continued\n' and see wehen there are differences.

(0005125) geoffclare (manager) 2020-12-01 16:28	Re Note: 0005124 Looks like you've identified a related problem with this text at the end of 2.8.1: In all of the cases shown in the table where an interactive shell is required not to exit, the shell shall not perform any further processing of the command in which the error occurred. I think this should change to: In all of the cases shown in the table where an interactive shell is required not to exit and a non-interactive shell is required to exit, an interactive shell shall not perform any further processing of the command in which the error occurred. (The subshell-of-an-interactive-shell behaviour is already the subject of bug 0001384.)

(0005129) kre (reporter) 2020-12-01 18:40 edited on: 2020-12-01 19:13	Re bugnote: 5125 First, for subshells, yes, 0001384 will take care of that. For the rest, the proposed change leaves unspecified (I believe) just what "the command" in "the command in which the error occurred" actually is. Clearly the actual simple command (usually) which fails should not be executed any further, but if that command is a part of a pipeline, or a list, or is embedded in a function, or ... (there are many possibilities) then is only that one simple command not executed, and everything else should continue (an interesting concept with something like: grep foo /some/file \| command eval 'nonsense ><;' \| wc -l and I'm not sure how I'd do that), or is something more than just "the command" to not be executed, and if so, how much, and how do we specify that. I did a little more testing after sending Note: 0005124, and found that with the command line eval 'nonsense ><; foobar'; printf 'continued\n' given to an interactive shell, yash, bash, ksh93, and zsh print "continued" whereas the ash derived shells (dash, FreeBSD (my version is getting old now) and NetBSD), and bosh and mksh do not. bosh and mksh also do not print "continued" when the command line is changed to be: command eval 'nonsense ><; foobar'; printf 'continued\n' whereas the ash derived shells do. The others (naturally) continue to print it. When not interactive, executing $SHELL -c "eval 'nonsense ><; foobar'; printf 'continued\n'" ksh93 and zsh still print "continued" (as does bash when not in posix mode). The other shells tested (including bash in posix mode) do not. With the "command" prefix, that is: $SHELL -c "command eval 'nonsense ><; foobar'; printf 'continued\n'" we cannot test zsh, as its "command" command ignores builtins (special or not) and only runs filesystem commands, and my system (NetBSD) has no filesystem command for "eval" (as a special builtin, one isn't required, but the same happens with "eval cd ..." with zsh as we don't have a cd filesystem command either). It does however still print "continued". Of the others all except yash bosh and mksh print "continued" (yash actually reports 2 syntax errors, one for each of the < and > redirect operators which are both missing operands). It does that with or without the "command" command being used. My summary is that bosh and mksh simply return to the PS1 prompt level on any "must exit" error, regardless of the use of "command" and then if non-interactive just exit. That seems broken. Perhaps. bash in non-posix mode basically ignores the "special" in special builtin I think, which explains its behaviour then. Explaining what ksh93 and yash do is harder. For interactive shells there's a clear difference between the ash derived shells and the others (the ones not already discounted as broken) over just how much "command" should be aborted on an otherwise "must exit" error. Note that in the above tests, none of the shells attempted to run "foobar" (ie: that never elicited a command not found error message ... there is no "foobar" command (or function, or anything similar) on my system). For the pipeline case above, I actually just tested: grep NetBSD /etc/motd \| eval 'nonsense ><;' \| wc -l and grep NetBSD /etc/motd \| command eval 'nonsense ><;' \| wc -l Much to my surprise all shells (really all) went ahead and ran the pipeline (both cases) and printed "0" as the line count (The word NetBSD does in appear in /etc/motd). The grep is also run, as when I used (cut and paste from above) "/some/file" I got an error from grep (all shells) about that file not existing. This might be explained by the commands in a pipeline being run in a sub-shell environment, but only really if each command in the pipeline is run in its own environment. For the case of functions, given a function definition badfunc() { $1 eval 'nonsense ><;' printf 'continued\n' } interactive shells printed "continued" exactly in the same cases as above (when the function was called as "badfunc" and "badfunc command". When that was run in a non-interactive shell $SHELL -c "badfunc() { $1 eval 'nonsense ><;' printf 'continued\n' } badfunc command badfunc printf 'done\n'" again the results were more or less as above (including the difference for bash in or not in posix mode) - except that the ash derived shells seem to ignore the "command" use (passed as an arg to badfunc) never print "continued" at all, and only issue one syntax error. bash in posix mode generates a syntax error for each call of badfunc, but never prints "continued", it does not print "done". mksh is similar to bash in posix mode here, but does print "done". bash (in non-posix mode) ksh93, and zsh, are the only shells that print "continued" (twice) along with 2 error messages (they also all print done). yash probably is closest to being "correct" (whatever that is) - it prints 2 syntax error messages, and nothing else. All this looks like a giant mess to me. For what it is worth, this is an area I have no problems with making changes to the way the NetBSD shell works, if we can ever arrive at a sensible definition of what should be done in all of these cases.

(0005271) Don Cragun (manager) 2021-03-15 15:27	Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- The standard is unclear about whether the shell shall exit when there is a special built-in utility error if the special built-in was executed via the command utility. The "Consequences of Shell Errors" says that the shell shall exit, but the description of the command utility says that the command utility suppresses the exit. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 2364 in the "Special built-in utility error" row of the table in 2.8.1 add a 1 superscript after "shall exit" in the "Non-Interactive Shell" column. Renumber the other superscripts and notes. After the table insert a new note 1: The shell shall exit only if the special built-in utility is executed directly. If it is executed via the command utility, the shell shall not exit. On page 2364 lines 75449-75450, change: In all of the cases shown in the table where an interactive shell is required not to exit, the shell shall not perform any further processing of the command in which the error occurred. to: In all of the cases shown in the table where an interactive shell is required not to exit and a non-interactive shell is required to exit, an interactive shell shall not perform any further processing of the command in which the error occurred.

(0005272) agadmin (administrator) 2021-03-15 19:42	Interpretation Proposed: 15 March 2021

(0005323) agadmin (administrator) 2021-04-19 13:48	Approved: 19 April 2021

Issue History
Date Modified	Username	Field	Change
2020-11-26 15:21	geoffclare	New Issue
2020-11-26 15:21	geoffclare	Name	=> Geoff Clare
2020-11-26 15:21	geoffclare	Organization	=> The Open Group
2020-11-26 15:21	geoffclare	Section	=> 2.8.1 Consequences of Shell Errors
2020-11-26 15:21	geoffclare	Page Number	=> 2364
2020-11-26 15:21	geoffclare	Line Number	=> 75421
2020-11-26 15:21	geoffclare	Interp Status	=> ---
2020-11-30 19:36	kre	Note Added: 0005124
2020-11-30 19:37	kre	Note Edited: 0005124
2020-12-01 16:28	geoffclare	Note Added: 0005125
2020-12-01 16:28	geoffclare	Relationship added	related to 0001384
2020-12-01 18:40	kre	Note Added: 0005129
2020-12-01 19:13	kre	Note Edited: 0005129
2021-03-15 15:27	Don Cragun	Interp Status	--- => Pending
2021-03-15 15:27	Don Cragun	Note Added: 0005271
2021-03-15 15:27	Don Cragun	Status	New => Interpretation Required
2021-03-15 15:27	Don Cragun	Resolution	Open => Accepted As Marked
2021-03-15 15:28	Don Cragun	Final Accepted Text	=> See Note: 0005271
2021-03-15 15:28	Don Cragun	Tag Attached: tc3-2008
2021-03-15 19:42	agadmin	Interp Status	Pending => Proposed
2021-03-15 19:42	agadmin	Note Added: 0005272
2021-04-19 13:48	agadmin	Interp Status	Proposed => Approved
2021-04-19 13:48	agadmin	Note Added: 0005323
2021-04-27 09:11	geoffclare	Status	Interpretation Required => Applied
2024-06-11 09:08	agadmin	Status	Applied => Closed

Aardvark Mark IV