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


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

exiting noninteractive shells on 'shift 2'

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

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


Contents

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

#14781 — exiting noninteractive shells on 'shift 2'

FromEric Blake <eblake@redhat.com>
Date2018-11-08 14:37 -0600
Subjectexiting noninteractive shells on 'shift 2'
Message-ID<mailman.3668.1541710058.1284.bug-bash@gnu.org>
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:

$ bash -c 'set 1
 > shift 2
 > echo "oops"'
oops
$ bash -c 'set 1; set -o posix
 > shift 2
 > echo "oops"'
oops

I spent more than an hour today figuring out why my shell script was 
inf-looping, and traced it back to failure to check for non-zero status 
from 'shift 2', where I had been expecting immediate hard failure of the 
entire script.  I don't care if bash doesn't hard-exit when not in POSIX 
mode, and it must not hard-exit when in interactive use; but the 
non-interactive use not doing a hard exit seems like a bug.

On the other hand, the POSIX wording for shift, under EXIT STATUS, 
weakens the "shall fail" from the earlier table into a weaker "may fail":

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#shift

     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.

Tested on Fedora 28 with bash-4.4.23-1.fc28.x86_64

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