RFC: 3 shells (ash, dash, bash), 3 different behaviours

[ibid.ag at gmail.com]

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 <cii at axis.com>
> > Reply-To: "busybox at busybox.net" <busybox at busybox.net>
> > To: "busybox at busybox.net" <busybox at busybox.net>
> > 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