On 11/8/18 6:03 PM, Chet Ramey wrote:
On 11/8/18 3:37 PM, Eric Blake wrote:
If I'm reading POSIX correctly, shift is a special built-in utility, and if
'$#' is 0 or 1, then 'shift 2' counts as a utility error that shall exit
the shell, per the table in 2.8.1 Consequences of Shell Errors:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
dash gets this right:
$ dash -c 'set 1
shift 2
echo "oops"'
dash: 2: shift: can't shift that many
but bash happily lets 'shift 2' fail with $? set to 1 but continues on with
execution of the rest of the script, even when in POSIX mode:
As you later note:
"If the n operand is invalid or is greater than "$#", this may be
considered a syntax error and a non-interactive shell may exit; if the
shell does not exit in this case, a non-zero exit status shall be returned.
Otherwise, zero shall be returned."
So the bash behavior is not a conformance issue, and allowed by the
standard.
Well, there's STILL a conformance issue - the standard requires that
unless documented otherwise, any time a command line tool exits with
non-zero status, that it outputs a message to stderr explaining the
error. The page for 'shift' does not document an exception for an exit
status of 1 being silent, yet bash is completely silent when 'shift 2'
returns non-zero status. Producing an error message to stderr would
call the developer's attention to the bug in their script and the fact
that bash did not shift out 1 argument, whether or not you also change
bash to exit the script or continue with execution.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
