[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in 'set -n' processing

From: Chet Ramey
Subject: Re: bug in 'set -n' processing
Date: Sat, 04 Jun 2011 10:35:03 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

On 6/3/11 2:39 PM, Eric Blake wrote:
> Bash has a bug: ${+} is syntactically invalid, as evidenced by the error
> message when running the script, yet using 'set -n' was not able to flag
> it as an error.

It's an invalid word expansion, not a syntax error.  To the parser, `${+}'
is a correctly-formed word: it doesn't contain any unquoted shell
metacharacters, and it doesn't require additional processing to determine
where the word ends.  You don't find out it's an invalid expansion until
you try to expand it.

The shell isn't required to perform expansions until it executes commands.
Since `set -n' inhibits command execution, it doesn't have to attempt any

Shells are allowed, but not required, to peek into words at parse time to
determine whether or not they will result in expansion errors.  Posix
allows an implementation to treat them as syntax errors if it can detect
them during tokenization.  ksh93 does that; bash does not.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]