shell parsing bug with &>

[Denys Vlasenko]

On Monday 03 September 2012 18:40, Rich Felker wrote:
> On Mon, Sep 03, 2012 at 12:58:37PM +0200, Denys Vlasenko wrote:
> > On Sun, Sep 2, 2012 at 11:21 PM, Rich Felker <dalias at aerifal.cx> wrote:
> > > It seems busybox ash is misinterpreting "&>" as having some special
> > > meaning rather than being a "&" token followed by a ">" token. I've
> > > filed a bug report:
> > >
> > > https://bugs.busybox.net/show_bug.cgi?id=5498
> > 
> > Set CONFIG_ASH_BASH_COMPAT to "no" and it will stop doing that.
> 
> Indeed I tested and this fixes the problem. But all the other reasons
> to turn CONFIG_ASH_BASH_COMPAT off just seem to be minimizing binary
> size;

I see it as a choice between two situations:

1. "I have my own system where I control all scripts, and can
make sure they all use only standard shell syntax"
 and
2. "I have to support stripts which use bashishm and I can't
convert them, give me as close to bash behavior as you can".

Apparently you are in situation #1 (you write your own script
which clearly can't even be run by bash correctly), so why
selecting CONFIG_ASH_BASH_COMPAT=n is not a good option for you?

> To resolve this issue, I'd really like to see either the option split
> out into harmless bash extensions vs incompatible bash extensions,

Wouldn't it be a "maze of zillion configuration opts" disease?

> or just a note added to the documentation in configure that
> CONFIG_ASH_BASH_COMPAT can break the parsing of conforming scripts
> (rather than just adding extensions that won't break anything).

Yes, this is acceptable