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 <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
