On Mon, Jul 11, 2011 at 00:56, Mike Frysinger wrote:
> On Sunday, July 10, 2011 21:03:54 Rich Felker wrote:
>> On Sun, Jul 10, 2011 at 06:23:55PM +0100, Chris Rees wrote:
>> > So... do we need a separate ash and hush if ash doesn't need to be
>> > sh-compatible? I don't want to start a flamewar, but I think that
>> > portability is very important, and adding strange extensions means
>> > that people use code that breaks on other platforms, as you well know
>> > from the latest patches to gen_build.sh.
>> >
>> > Can we still call it ash if it doesn't behave like ash?
>> >
>> > Also, what about scripts that don't expect { to be a special
>> > character, what happens then?
>>
>> This is why there's "set -B". The defautl in bash is to enable brace
>> expansion for interactive shells (where standards supposedly don't
>> matter) and disable it for non-interactive ones (e.g. running
>> scripts). But you can override it either way with "set -B" or "set +B".
>
> in addition to that, the braces only get expanded if the usage warrants it.
> so if the braces are quoted, or dont follow the simple syntax, the braces get
> passed through like any other char.
>
> $ echo {0..10
> {0..10
> $ echo '{0..10}'
> {0..10}
>
> i doubt many scripts will hit this
sorry, i realized this isnt quite what we're talking about. but the
example still holds:
$ echo abc{d,e,f,g
abc{d,e,f,g
$ echo 'abc{d,e,f,g}'
abc{d,e,f,g}
also worth noting that the brace is already a semi-reserved character
in POSIX itself. you get semi-subshells and functions with it. so
concern about it being reserved is kind of a red herring.
from POSIX:
$ { echo hi; }
hi
$ f() { echo hi; }; f
hi
-mike
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
