Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Matt Zimmerman <mdz@debian.org>]

On Mon, Apr 30, 2001 at 12:16:16PM -0700, Zack Weinberg wrote:

> [whose words are these? unattributed in your mail]
> > Sorry, but this is broken.  This assumes that IFS is set to begin with
> > which may not be the case.
> 
> I have consulted the Single Unix Standard and can find only dubious
> justification for this assertion.  It never flat out says whether IFS
> is to be set on entry to the shell or not.  However, I note this
> paragraph:
> 
> # IFS
> #    Input field separators: a string treated as a list of characters
> #    that is used for field splitting and to split lines into fields
> #    with the read command. If IFS is not set, the shell will behave
> #    as if the value of IFS were the space, tab and newline
> #    characters. (See Field Splitting .)
> 
> I could read that as requiring that if IFS is unset, then you get
> "<space><tab><newline>" if you inspect its value, NOT the null string.

I have to disagree with this interpretation.  The sentence above specifies that
"the shell will behave _as if_ the value of IFS were..." (emphasis added).
This implies that IFS does not necessarily have any value at all, and its value
certainly should not be relied upon.  If the intention were to have a default
value for the IFS variable, it would have been much more straightforward to say
"If IFS is not set, the shell will assign it the value..."

Of course, it seems that this behavior is different from that of traditional
Bourne shell implementations, so I think I have to agree that ash should avoid
diverging from tradition in order to adhere to a relatively new standard.

-- 
 - mdz