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 eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
