Re: More fun with IFS

[Dan Douglas]

On Sunday, February 24, 2013 10:26:52 PM Thorsten Glaser wrote:
> Dan Douglas dixit:
> 
> >Zsh and pdkshes produce:
> >
> >one:::two:three:::four
> >
> >For all of the above, which I think is wrong for the last 4. ksh93
> >produces:
> 
> Why is it incorrect?

This test was intended to demonstrate expansions within assignment contexts. 
''one:::two'' and ''three:::four'' are separate arguments to begin with. Word 
splitting and pathname expansion shouldn't occur within (ordinary) assignment 
contexts. I think the mksh (and zsh) results are wrong because I can't think 
of any reason it should be inserting a '':'' between the two arguments, 
especially for the ''$@'' variants, either quoted or unquoted. It certainly 
can't be because of a word splitting step.

It's already been pointed out that different shells interpret unquoted @ and * 
differently. I think Chet's interpretation of the spec is the most reasonable 
(but you could argue otherwise):

http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00180.html

Most script writers treat assignments as identical whether quoted or not. 
Quotes should only be needed to assign whitespace-containing strings and 
$'...' quotes, but shouldn't affect globbing or word splitting or modify the 
expansion in any other way. You'll notice the same thing in the case of 
herestrings.

 $ mksh -c 'set one:::two three:::four; IFS=:; cat <<<$@'
one:::two:three:::four
 $ mksh -c 'set one:::two three:::four; IFS=:; cat <<<"$@"'
one:::two:three:::four
 $ ksh -c 'set one:::two three:::four; IFS=:; cat <<<"$@"'
one:::two three:::four
 $ ksh -c 'set one:::two three:::four; IFS=:; cat <<<$@'
one:::two three:::four
 $ bash -c 'set one:::two three:::four; IFS=:; cat <<<$@'
one   two three   four
 $ bash -c 'set one:::two three:::four; IFS=:; cat <<<"$@"'
one:::two three:::four

I tend to think AT&T ksh is doing the most reasonable thing here by making the 
concatenated result exactly the same as if expanded as arguments in a quoted 
context, with whitespace separating them.
 
> In other words, “don’t do that then” (rely on this behaviour).

I wouldn't bother with this language if the only non-random behavior was that 
specified by POSIX. "POSIX doesn't specify it" is a horrible reason to do 
anything.

> I think eval is evil anyway ;-)

Eval is frowned upon because it almost always misused. Until shells add first-
class closures and higher-order functions I'll continue using it.

> (Thanks to ormaaj for pointing out this posting.)

:)

-- 
Dan Douglas