Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14784 > unrolled thread

Re: exiting noninteractive shells on 'shift 2'

Started byEric Blake <eblake@redhat.com>
First post2018-11-09 08:47 -0600
Last post2018-11-09 08:47 -0600
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: exiting noninteractive shells on 'shift 2' Eric Blake <eblake@redhat.com> - 2018-11-09 08:47 -0600

#14784 — Re: exiting noninteractive shells on 'shift 2'

FromEric Blake <eblake@redhat.com>
Date2018-11-09 08:47 -0600
SubjectRe: exiting noninteractive shells on 'shift 2'
Message-ID<mailman.3742.1541774877.1284.bug-bash@gnu.org>
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

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web