On Fri, Mar 14, 2014 at 12:24:51AM +0100, Cristian Ionescu-Idbohrn wrote: > On Thu, 13 Mar 2014, Cristian Ionescu-Idbohrn wrote: > > > Date: Thu, 13 Mar 2014 21:00:32 +0100 > > From: Cristian Ionescu-Idbohrn <[email protected]> > > Reply-To: "[email protected]" <[email protected]> > > To: "[email protected]" <[email protected]> > > Subject: RFC: 3 shells (ash, dash, bash), 3 different behaviours > > > > 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: > > Reading this again: > > > 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 mother tongue isn't english, but what I make of it is that the > shell may ignore an environment IFS set outside a shell(script)?. > Thoughts? > Correct.
If you use either of these: export IFS=" -_"; sh #or ./script.sh ... IFS=" -_" sh the shell is _permitted_ (but not required) to ignore the value of IFS. The reverse sequence, sh $ IFS=" -_" cannot be ignored, however. So the shell could unconditionally unset IFS on start. HTH, Isaac Dunham _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
