On Thursday 13 March 2014 21:00, Cristian Ionescu-Idbohrn wrote: > It's explained here: > > http://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html > > IFS > > (Input Field Separators.) A string treated as a list of > characters that shall be used for field splitting and to split > lines into words with the read command. See Field Splitting. > If IFS is not set, the shell shall behave as if the value of > IFS were <space>, <tab>, and <newline>. > Implementations may ignore the value of IFS in the environment > at the time sh is invoked, treating IFS as if it were not set. > > What bothers me is the last phrase: > > Implementations may ignore the value of IFS in the environment > at the time sh is invoked, treating IFS as if it were not set. > > My expectation is the shell _should_ show the way it would behave, > should IFS be used after unset. That's clearly not the case :( > > Consider the attached example and run with: > > $ {busybox ash,bash,dash} /path/to/IFS-and-busybox-ash.example.sh > > IFS is a special (not ordinary) variable. What I'd intuively expect > is: > > local IFS > > would be an upper scope copy, or if unset: > > IFS=<space><tab><newline> > > I'm confused :(
No, IFS isn't magically get set: "If IFS is not set, the shell shall behave as if the value of IFS were <space>, <tab>, and <newline>" Shell doesn't set it. If IFS is not set, shell only performs word splitting as if IFS='<space><tab><newline>'. So far from your example I only see that there is a difference how "local VAR" is treated: on encountering this command, ash doesn't clear VAR, whereas bash and hush unset it. Correct? _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
