positional argument bug

positional argument bug

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

[originally brought up on the bash list as a NetBSD bug, but dash is
also affected]

On 05/05/2011 08:11 AM, Eric Blake wrote:
>> I'd call that a pretty serious incompatibility on the part of ash and its
>> descendants (BSD sh, dash, etc.).  There's no good reason that
>>
>> set -- a b c d e f g h i j
>> echo $10
>>
>> should echo `j'.
> 
> Also a POSIX violation:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
> 
> "The parameter name or symbol can be enclosed in braces, which are
> optional except for positional parameters with more than one digit or
> when parameter is followed by a character that could be interpreted as
> part of the name."

Additionally from POSIX:

"If the parameter name or symbol is not enclosed in braces, the
expansion shall use the longest valid name (see XBD Name)"

"In the shell command language, a word consisting solely of underscores,
digits, and alphabetics from the portable character set. The first
character of a name is not a digit."

Therefore, in "$10", 10 is not a name, so the longest name is the empty
string, and the single-character symbol is used instead, such that this
MUST be parsed as ${1}0, not as ${10}.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: positional argument bug

[Oleg Verych]

2011/5/5 Eric Blake <eblake@redhat.com>:
> [originally brought up on the bash list as a NetBSD bug, but dash is
> also affected]

So what? I was happy (years back) to have ability to create adressable
arrays using $####... or ${####} if it matters.

> Therefore, in "$10", 10 is not a name, so the longest name is the empty
> string, and the single-character symbol is used instead, such that this
> MUST be parsed as ${1}0, not as ${10}.

IMHO this would be step back.
-- 
sed 'sed && sh + olecom = love'  <<  ''
-o--=O`C
 #oo'L O
<___=E M

Re: positional argument bug

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

On 05/05/2011 09:47 AM, Oleg Verych wrote:
> 2011/5/5 Eric Blake <eblake@redhat.com>:
>> [originally brought up on the bash list as a NetBSD bug, but dash is
>> also affected]
> 
> So what? I was happy (years back) to have ability to create adressable
> arrays using $####... or ${####} if it matters.

You can always create an addressable array with ${####} - the bug in
question is only about dash's treatment of $####.  POSIX already
requires that the user use braces for multi-digit positional parameters.

> 
>> Therefore, in "$10", 10 is not a name, so the longest name is the empty
>> string, and the single-character symbol is used instead, such that this
>> MUST be parsed as ${1}0, not as ${10}.
> 
> IMHO this would be step back.

No, making $10 different from ${10} would be making things
POSIX-compliant.  And I can envision using things like:

set a
eval echo \$$10

as a way to specifically echo the contents of $a0, but where that usage
only works if all shells follow the same rules.  But given the current
difference in behavior, I guess:

eval echo \$${1}0

is the best I can expect.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: positional argument bug

[Herbert Xu]

Eric Blake <eblake@redhat.com> wrote:
>
>> Also a POSIX violation:
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
>> 
>> "The parameter name or symbol can be enclosed in braces, which are
>> optional except for positional parameters with more than one digit or
>> when parameter is followed by a character that could be interpreted as
>> part of the name."
> 
> Additionally from POSIX:
> 
> "If the parameter name or symbol is not enclosed in braces, the
> expansion shall use the longest valid name (see XBD Name)"
> 
> "In the shell command language, a word consisting solely of underscores,
> digits, and alphabetics from the portable character set. The first
> character of a name is not a digit."
> 
> Therefore, in "$10", 10 is not a name, so the longest name is the empty
> string, and the single-character symbol is used instead, such that this
> MUST be parsed as ${1}0, not as ${10}.

I don't think any of this explicitly states that $10 cannot be
interpreted as ${10}.  All it says is that where the first character
is an underscore or alphabetic, then the longest name should be
used, and that to use $10 portably you must put braces around it.

So I'm not going to make any changes at this point.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: positional argument bug

[Harald van Dijk]

On Sat, 2011-05-21 at 09:59 +1000, Herbert Xu wrote:
> Eric Blake <eblake@redhat.com> wrote:
> >
> >> Also a POSIX violation:
> >> 
> >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
> >> 
> >> "The parameter name or symbol can be enclosed in braces, which are
> >> optional except for positional parameters with more than one digit or
> >> when parameter is followed by a character that could be interpreted as
> >> part of the name."
> > 
> > Additionally from POSIX:
> > 
> > "If the parameter name or symbol is not enclosed in braces, the
> > expansion shall use the longest valid name (see XBD Name)"
> > 
> > "In the shell command language, a word consisting solely of underscores,
> > digits, and alphabetics from the portable character set. The first
> > character of a name is not a digit."
> > 
> > Therefore, in "$10", 10 is not a name, so the longest name is the empty
> > string, and the single-character symbol is used instead, such that this
> > MUST be parsed as ${1}0, not as ${10}.
> 
> I don't think any of this explicitly states that $10 cannot be
> interpreted as ${10}.  All it says is that where the first character
> is an underscore or alphabetic, then the longest name should be
> used, and that to use $10 portably you must put braces around it.

I agree that the last quotes are not convincing. In fact, they seem to
be saying that $10 must be interpreted as ${}10: there's no "if there is
no name, use a single-character symbol". The first, however:

> "The parameter name or symbol can be enclosed in braces, which are
> optional except for positional parameters with more than one digit or
> when parameter is followed by a character that could be interpreted as
> part of the name."

does say the braces are optional in ${1}0, so if a script author changes
${1}0 to $10, there should be no change in behaviour.

Cheers,
Harald

Re: positional argument bug

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On 05/21/2011 02:53 AM, Harald van Dijk wrote:
>>> Additionally from POSIX:
>>>
>>> "If the parameter name or symbol is not enclosed in braces, the
>>> expansion shall use the longest valid name (see XBD Name)"
>>>
>>> "In the shell command language, a word consisting solely of underscores,
>>> digits, and alphabetics from the portable character set. The first
>>> character of a name is not a digit."
>>>
>>> Therefore, in "$10", 10 is not a name, so the longest name is the empty
>>> string, and the single-character symbol is used instead, such that this
>>> MUST be parsed as ${1}0, not as ${10}.
>>
>> I don't think any of this explicitly states that $10 cannot be
>> interpreted as ${10}.  All it says is that where the first character
>> is an underscore or alphabetic, then the longest name should be
>> used, and that to use $10 portably you must put braces around it.
> 
> I agree that the last quotes are not convincing. In fact, they seem to
> be saying that $10 must be interpreted as ${}10: there's no "if there is
> no name, use a single-character symbol". The first, however:
> 
>> "The parameter name or symbol can be enclosed in braces, which are
>> optional except for positional parameters with more than one digit or
>> when parameter is followed by a character that could be interpreted as
>> part of the name."
> 
> does say the braces are optional in ${1}0, so if a script author changes
> ${1}0 to $10, there should be no change in behaviour.

Given the confusing wording in POSIX, I've opened up a bug report:

http://austingroupbugs.net/view.php?id=458

Once it is resolved, it will either put the burden on dash to become
compliant ($10 is unambiguously ${1}0, Option 1), or put the burden on
compliant shell scripts to avoid $10 (both historical ${1}0 and dash
${10} behaviors are permitted, Option 2).  It will be interesting to see
which way the POSIX folks go on this one.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]