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

[Denys Vlasenko]

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?