* shift "fatal error"
@ 2011-03-10 18:40 Dan Muresan
2011-03-10 19:23 ` Guido Berhoerster
0 siblings, 1 reply; 5+ messages in thread
From: Dan Muresan @ 2011-03-10 18:40 UTC (permalink / raw)
To: dash
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shift "fatal error"
2011-03-10 18:40 shift "fatal error" Dan Muresan
@ 2011-03-10 19:23 ` Guido Berhoerster
2011-03-15 21:31 ` Jilles Tjoelker
0 siblings, 1 reply; 5+ messages in thread
From: Guido Berhoerster @ 2011-03-10 19:23 UTC (permalink / raw)
To: Dan Muresan; +Cc: dash
* 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shift "fatal error"
2011-03-10 19:23 ` Guido Berhoerster
@ 2011-03-15 21:31 ` Jilles Tjoelker
2011-03-26 7:11 ` Dan Muresan
0 siblings, 1 reply; 5+ messages in thread
From: Jilles Tjoelker @ 2011-03-15 21:31 UTC (permalink / raw)
To: Dan Muresan, dash
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shift "fatal error"
2011-03-15 21:31 ` Jilles Tjoelker
@ 2011-03-26 7:11 ` Dan Muresan
2011-03-26 7:27 ` Jonathan Nieder
0 siblings, 1 reply; 5+ messages in thread
From: Dan Muresan @ 2011-03-26 7:11 UTC (permalink / raw)
To: Jilles Tjoelker; +Cc: dash
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shift "fatal error"
2011-03-26 7:11 ` Dan Muresan
@ 2011-03-26 7:27 ` Jonathan Nieder
0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Nieder @ 2011-03-26 7:27 UTC (permalink / raw)
To: Dan Muresan; +Cc: Jilles Tjoelker, dash
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-26 7:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-10 18:40 shift "fatal error" Dan Muresan
2011-03-10 19:23 ` Guido Berhoerster
2011-03-15 21:31 ` Jilles Tjoelker
2011-03-26 7:11 ` Dan Muresan
2011-03-26 7:27 ` Jonathan Nieder
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).