NetBSD-Bugs archive

[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." <>
To: Alan Barrett <>
 Roland Illig <>
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:
 >>>> How-To-Repeat:
 >>> $ 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  
 >> implications
 >> 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
 > category.
 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  
 is stated:
        "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  
 positional parameters:
      The exit status is >0 if n>$#; otherwise, it is zero.
 (from <URL: 
 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.

Home | Main Index | Thread Index | Old Index