Re: bug batch

[Eric Blake]

On 06/13/2013 11:24 AM, Dan Douglas wrote:
> On Thursday, June 13, 2013 02:54:57 AM Linda Walsh wrote:
>> I can't speak to all your cases, but I had comments on a few:
>>
>> Dan Douglas wrote:
>>
>>> Most shells (and GCC) consider not grouping the assignment in a situation
>>> like this an error. Bash tolerates it, apparently reversing associativity:
>>>
>>>     : $((1 == x = 1)) # Error in dash/ksh/mksh/zsh/etc
>> ---- If you do it without the ':', it returns a false status.  The colon
>> doesn't seems to return true or false based on whether or not there was a
>> syntactic error, but not for a command that runs normally and returns any
>> status.
> 
> The colon and status aren't relevant to this test. It's an illegal arithmetic
> expression because the comparison should be evaluated before the assignment,
> throwing a fatal shell error because the assignment lacks an identifier on the
> LHS. It might not cause any ambiguity the way Bash is currently doing it, it
> just won't warn of the ensuing portability problem.

POSIX says that any $(()) expression that cannot be parsed as arithmetic
is then evaluated as if it were $( ( 1 == x = 1 ) ) (that is, a command
substitution of a subshell that attempts to invoke the command named
'1').  This is not a syntax error, but is an error if there is no
command named '1'.

Whether various shells have extensions that attempt to treat the command
as arithmetic or fall back to command substitution is a different
matter, since POSIX doesn't forbid extensions.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature