Re: exiting noninteractive shells on 'shift 2'

[Eric Blake]

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