On Sun, 16 Mar 2014, Denys Vlasenko wrote: > 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>'.
Yes. I think I got better understanding now of what's going on. Please take a look at the whole thread, and specially latest message. > 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. If I'm not mistaking, the latest example shows that the shell behaves as if IFS=<space><tab><newline>. Nevertheless, the 3 shells I tested the script with behave a bit different. The devil is in the details, I guess. WRT script line the error is associated to, it seems dash is doing the best jobb ("14: parameter not set", printed when trying to print IFS, immediately after unsetting it). ash reports the error on the line function f is called. That seems to be the only difference between dash and ash. bash reports 2 errors "line 11: IFS: unbound variable" and "line 14: IFS: unbound variable". Yes, I tested with zsh too. It just exits, even though the command line tell it explicitly not to: 14 printf '%s' "$IFS" | hd || : ^^^^ But that's another story :) Cheers, -- Cristian _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox