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

[Cristian Ionescu-Idbohrn]

On Sun, 16 Mar 2014, Denys Vlasenko wrote:
> 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>'.

Yes.  I think I got better understanding now of what's going on.
Please take a look at the whole thread, and specially latest message.

> 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.

If I'm not mistaking, the latest example shows that the shell behaves
as if IFS=<space><tab><newline>.  Nevertheless, the 3 shells I tested
the script with behave a bit different.  The devil is in the details,
I guess.

WRT script line the error is associated to, it seems dash is doing the
best jobb ("14: parameter not set", printed when trying to print
IFS, immediately after unsetting it).  ash reports the error on the
line function f is called.  That seems to be the only difference
between dash and ash.  bash reports 2 errors "line 11: IFS: unbound
variable" and "line 14: IFS: unbound variable".  Yes, I tested with
zsh too.  It just exits, even though the command line tell it
explicitly not to:

	14	printf '%s' "$IFS" | hd || :
		                        ^^^^

But that's another story :)


Cheers,

-- 
Cristian