shift "fatal error"

shift "fatal error"

[Dan Muresan]

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

-- Dan

Re: shift "fatal error"

[Guido Berhoerster]

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

-- 
Guido Berhoerster

Re: shift "fatal error"

[Jilles Tjoelker]

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

Re: shift "fatal error"

[Dan Muresan]

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

After reading the other part of the spec (about syntax errors in
utilities), I reached the conclusion that dash has just enough excuses
in the spec and in history to behave as it currently does -- so
presumably nothing will change (especially since the current behavior
*reduces* usability).

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

Yes, that was the main point, but it's true that specs can be
self-contradictory.

> 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

That's how I would have thought any reasonable person would interpret
the blurb about syntax errors in special built-ins, but apparently
there are other ways to see it, rooted in historical precedent even.

-- Dan

Re: shift "fatal error"

[Jonathan Nieder]

Dan Muresan wrote:

> After reading the other part of the spec (about syntax errors in
> utilities), I reached the conclusion that dash has just enough excuses
> in the spec and in history to behave as it currently does

I have no strong opinion about this (and indeed the spec and history
not giving a clear answer reduces my motivation) but if you'd like to
change the spec, it's very easy.  See

 http://www.opengroup.org/austin/

Hope that helps,
Jonathan