Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001427 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-11-26 15:21 2020-12-01 18:40
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Geoff Clare
Organization The Open Group
User Reference
Section 2.8.1 Consequences of Shell Errors
Page Number 2364
Line Number 75421
Interp Status ---
Final Accepted Text
Summary 0001427: 2.8.1 does not take into account "command"
Description The table in XCU 2.8.1 does not take account of the fact that when the command utility is used, it prevents the shell from aborting when an error occurs in a special built-in utility, as per this statement in the description of command:
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 Section 2.14 (on page 2384) shall not occur.

Desired Action 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. 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.

Tags No tags attached.
Attached Files

- Relationships
related to 0001384Resolved Subshell of an interactive shell is effectively non-interactive 

-  Notes
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.

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.)
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

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"

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
    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
    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.

- 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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker