[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/37493: /bin/sh exits if shift fails, but shouldn't
The following reply was made to PR bin/37493; it has been noted by GNATS.
From: "Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>
To: Alan Barrett <apb%cequrux.com@localhost>
Roland Illig <roland.illig%gmx.de@localhost>
Subject: Re: bin/37493: /bin/sh exits if shift fails, but shouldn't
Date: Sun, 25 May 2008 11:44:22 -0400
On 25-May-08, at 5:49 AM, Alan Barrett wrote:
> On Sun, 25 May 2008, David Holland wrote:
>>> $ sh -c 'set -ex; shift || echo failed.'
>>> + shift
>>> shift: can't shift that many
>> I'm thinking that shift should be changed to an ordinary builtin
>> instead of a special builtin. But I'm not sure what other
>> this might have. Would someone who understands the finer points of sh
>> like to comment?
> shift is required to be a special built-in utility
> According to one part of SUSv3, syntax errors in
> special built-in utilities are permitted, but
> not required, to make the shell exit immediately
A plain "shift" command, as in the original example above, is never a
"syntax" error in that form regardless of whether the command itself
can perform the required operation or not. The syntax of the command
as given is itself correct.
> According to another part of SUSv3, an "option or operand error"
> in a special built-in utility means that the shell must exit
> I think that trying to shift too many parameters would fall under this
As I will show below this is effectively a data error, not anything to
do with command options or operands (or syntax).
This next quote is slightly out of context, but in XBD Chapter 12 it
"The requirement on the standard utilities is that numbers in the
specified range do not cause a syntax error, although the
specification of a number need not be semantically correct for a
particular operand or option-argument of a utility."
So, the lack of any operand for "shift" is the same as an operand of
"1" ("If n is not given, it shall be assumed to be 1.") and as such
that number is well within the specified range ("The value n shall be
an unsigned decimal integer...") of valid operand values for the
"shift" command. Yes that second quote goes on to say something else
that could be construed to be an excuse for a syntax error, however I
would strongly suggest that it is then trumped by the following:
The standard does fully describe the required behaviour of the "shift"
utility when its operand value exceeds the number of remaining
The exit status is >0 if n>$#; otherwise, it is zero.
I.e. "shift" must not trigger a syntax error when its operand is
greater than the number of positional parameters remaining -- it must
exit with a non-zero status instead.
Greg A. Woods; Planix, Inc.
Main Index |
Thread Index |