shell parsing bug with &>

[Rich Felker]

On Sun, Sep 02, 2012 at 11:35:04PM +0200, Yann E. MORIN wrote:
> Rich, All,
> 
> On Sunday 02 September 2012 23:21:36 Rich Felker wrote:
> > It seems busybox ash is misinterpreting "&>" as having some special
> > meaning rather than being a "&" token followed by a ">" token.
> 
> The &> operator is not defined in POSIX. However, reading the bash manpage
> gives:
> 
> [--SNIP--]
>   Redirecting Standard Output and Standard Error
>     This construct allows both the standard output (file descriptor 1) and
>     the standard error output (file descriptor 2) to be redirected to the
>     file whose name is the expansion of word.
> 
>     There are two formats for redirecting standard output and standard
>     error:
>         &>word
>     and
>         >&word
> 
>     Of the two forms, the first is preferred.  This is semantically
>     equivalent to
>               >word 2>&1
> [--SNIP--]
> 
> ash can "include" some bash extensions if configured to. Not sure &> is
> part of the supported extnesions, though. Maybe you can check this in your
> busybox configuration.

Okay. The problem however is that unlike some other extensions, this
one breaks the grammar and causes valid programs to have different
behavior (rather than just making some otherwise-invalid programs
valid with new behavior). There should at least be a way to turn it
off.

Rich