Re: Use of double parentheses

[Eric Blake]

On 08/01/2011 09:51 AM, Paul Eggert wrote:
> On 08/01/11 08:21, Eric Blake wrote:
>>>>>    &&  ( (unset $as_var) || exit 1)>/dev/null 2>&1&&  unset $as_var || :
>>>> ...
>>>> It's not a bug in pdksh - POSIX was recently reworded to allow (( to
>>>> introduce arithmetic parsing on any shell that wants to provide it as an 
>>>> extension.
> 
>> http://austingroupbugs.net/view.php?id=217
> 
> Thanks for mentioning that; I didn't know it.  However,
> from that URL it still appears that pdksh is buggy.
> The new rule says that '((FOO))' is special if FOO
> is a syntactically valid arithmetic expression.
> But in the above example, the expression '((unset $asvar) ...)'
> surely would not be syntactically valid to pdksh,
> and therefore '((' should not be special there.

The problem is that:

((unset $asvar) ... )

can possibly be parsed as an incomplete arithmetic expression depending
on the contents of $asvar and whether 'unset' is currently used as a
shell variable; at which point pdksh is trying to parse until it finds
the terminating '))' (which might not occur before eof).

This gem from the same POSIX link demonstrates the problem with $(()):

    It is recommended that application writers always separate the
    "$(" and '(' with white space when a command substitution starts
    with a subshell, even if it is not a the simple case of a single
    subshell. More complicated ambiguous cases are possible, such
    as:

        $(( cat <<EOH
        + ( (
        EOH
        ) && ( cat <<EOH
        ) ) + 1 +
        EOH
        ))

    This is syntactically valid an arithmetic expansion, with cat and
    EOH as the names of shell variables.

Since that page also states (()) should be assumed to have the same
parse issues as $(()), I don't know whether we can declare pdksh as
buggy, or as merely supporting more extensions favoring arithmetic
parsing even on syntax that is not arithmetic in other shells.

Either way, I stick by my rule of thumb - NEVER use (( in portable
shell; always stick a space in there, rather than trying to second-guess
whether your particular choice of shell might have some extensions where
it could be parsed arithmetically or cause an ambiguous parse.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org