On Thu, 13 Mar 2014, Cristian Ionescu-Idbohrn wrote:
> Date: Thu, 13 Mar 2014 21:00:32 +0100
> From: Cristian Ionescu-Idbohrn <c...@axis.com>
> Reply-To: "busybox@busybox.net" <busybox@busybox.net>
> To: "busybox@busybox.net" <busybox@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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
