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
