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