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

[Cristian Ionescu-Idbohrn]

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


Cheers,

-- 
Cristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IFS-and-busybox-ash.example.sh
Type: application/x-sh
Size: 501 bytes
Desc: 
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140313/be19a390/attachment.sh>