On 06/30/2011 05:27 PM, Austin Group Bug Tracker wrote: > http://austingroupbugs.net/view.php?id=459#c880
> There is no reason to wait for the next revision of the standard to make
> this change.
> The change will not break any existing implementation and clarifies that
> invoking
> shift x (where x is an integral value larger than $#) is an error that may,
> but need
> not, be considered a syntax error. In this case it is unspecified whether
> or not a
> non-interactive shell will quit when this error is detected.
Or, in terms of the original question:
"... could you please clarify, whether it is "allowed" to specify values
n > $# to the shift special built-in or not or whether the results are
undefined."
Calling things "undefined" would mean that there are infinite possible
behaviors (core dump, reformat your drive, do nothing, ...), which there
are not. Rather, this bug interpretation has clarified that the results
of 'shift n # n > $#' are well-defined, but that the definition has 2
permissible behaviors. Both the current bash behavior of no syntax
error but non-zero status, as well as the current dash behavior of
exiting on a syntax error, conform to the standard. Therefore, the fact
that there are two equally valid behaviors means that an application
writer must be prepared for either behavior, and the original example:
while shift 1 2> /dev/null ; do
domeSomethingWith $1
done
is a case of a non-portable script because it was not prepared to handle
the syntax error, and not a case of a bug in dash.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
