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

[Cristian Ionescu-Idbohrn]

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?

> 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 :(


Cheers,

-- 
Cristian