Re: shift "fatal error"

[Jilles Tjoelker <jilles@stack.nl>]

On Thu, Mar 10, 2011 at 08:23:33PM +0100, Guido Berhoerster wrote:
> * Dan Muresan <danmbox@gmail.com> [2011-03-10 19:41]:
> > Hi, is there some consensus on whether shift should cause a "fatal
> > error" as reported by Herbert against bash:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252378
> > 
> > # doesn't print anything
> > dash -c 'shift 2; echo hi'
> > 
> > My copy of SUSv3 doesn't seem to imply any "fatal error" handling
> > requirement for shift:
> > 
> > --- 8-X ---
> > EXIT STATUS
> > 
> > The exit status is >0 if n>$#; otherwise, it is zero.
> > 
> > CONSEQUENCES OF ERRORS
> > 
> > Default.
> > --- 8-X ---

> For IEEE Std 1003.1-2008 see section 2.8.1 "Consequences of
> Shell Errors": a "utility syntax error (option or operand error)"
> with special built-ins shall cause the shell to exit. That's what
> dash, ksh93, and pdksh do.

That may have been the intention (considering that it matches the real
Bourne shell in addition to various flavours of Korn shell), but that is
not how I would interpret it. A too high shift count still seems
syntactically valid to me.

A statement about the exit status in a particular error situation also
usually indicates that the shell shall not abort.

Examples of shift commands that I think shall cause the shell to abort:
shift -S  # unless a -S option is supported as an extension
shift x   # unless arithmetic expressions are accepted as an extension
shift @   # unless there is some strange extension

The FreeBSD sh shift special builtin behaves this way (a too high shift
count is not fatal but a syntactically invalid number is). This was done
a few years ago when the syntax-error property of special builtins was
implemented, as making a too high shift count fatal caused a configure
script in the FreeBSD base system to fail.

I would not encourage the extension of accepting arithmetic expressions
because that requires a subtly different kind of arithmetic expression
without octal constants. POSIX is clear that 'shift 010' should shift
ten positions, not eight, while 'shift $((010))' should shift eight
positions.

-- 
Jilles Tjoelker