[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More fun with IFS
From: |
Dan Douglas |
Subject: |
Re: More fun with IFS |
Date: |
Tue, 26 Feb 2013 23:28:56 -0600 |
User-agent: |
KMail/4.8.3 (Linux/3.4.6-pf+; KDE/4.8.3; x86_64; ; ) |
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