[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exiting noninteractive shells on 'shift 2'

From: Eric Blake
Subject: Re: exiting noninteractive shells on 'shift 2'
Date: Fri, 9 Nov 2018 08:47:30 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

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:


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]