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
