On Mon, Sep 3, 2012 at 3:22 PM, Rich Felker wrote: > On Tue, Sep 04, 2012 at 12:12:35AM +0200, Denys Vlasenko wrote: >> 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 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". > > You left out #3: > > "I have to support scripts which assume the shell interpreter conforms > to the standard and which might be using & adjacent to > without an > intervening space."
which is pretty much #1 does your code *actually* want to do the equivalent of "& >" ? that's extremely unlikely: you're backgrounding everything before that point and starting off a new command with a redirect. yes, that is according to the standard correct, but i've never seen anyone do it. i.e. this snippet: some-cmd &>/dev/null ls is (according to POSIX) the same as: some-cmd & >/dev/null ls or the more common form: some-cmd & ls >/dev/null -mike _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
