Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: What's wrong with 12500?
- X-seq: zsh-workers 12611
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>, "ZSH workers mailing list" <zsh-workers@xxxxxxxxxxxxxx>
- Subject: Re: What's wrong with 12500?
- Date: Mon, 14 Aug 2000 08:28:29 +0000
- In-reply-to: <001001c005c1$c6847390$21c9ca95@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <001001c005c1$c6847390$21c9ca95@xxxxxxxxxxxxxx>
On Aug 14, 11:32am, Andrej Borsenkow wrote:
} Subject: What's wrong with 12500?
If you mean "Why hasn't 12500 been included in CVS?" then I suspect the
answer is simply that none of us SourceForge "developers" remembered to
apply and commit it. Not that I'm sure it needs to be committed ...
If you mean "Why does zsh behave that way?" here's the quandary:
read foo <<<'one '
Here, there's one variable and one field in the input. The result should
be foo="one". It's not that trailing whitespace was stripped, but rather
that the definition of "read a field and assign it to foo" means that there
should not be any whitespace in $foo.
Similarly, in:
read foo <<<' one'
There's still only one field in the input; there's no explicit "stripping"
of the leading whitespace, it's just ignored as an effect of parsing.
And again:
read foo bar <<<'one two '
Here again, foo="one" and bar="two" because there are two fields in the
input.
Now we come to the "leftover fields assigned to the last" rule:
read foo bar <<<'one two three '
Interpreted strictly, the input should be broken into fields before any
assignments take place. (Note that the space between "one" and "two" gets
consumed as part of parsing the first two fields and assigning those to
foo and bar, before zsh even discovers that there is "leftover" input.)
One might expect foo="one" bar="two three". It doesn't say "leftover raw
text is assigned", it says "leftover fields". You should be *expecting*
whitespace to be ignored; it shouldn't be necessary to talk about it
being "stripped".
But that isn't the way other shells behave, and zsh wants to act like sh
where it doesn't extend it, so it simply pastes the whole rest of the
string onto `bar'. But! If the rest of the string is *all* whitespace,
it has to behave as in the "two fields in the input" case above. So at
the very end of processing it does in fact strip trailing whitespace.
As I mentioned in 12505, this agrees with bash and disagrees with ash,
which are the only other shells I have to test against. Either way is
certainly within the bounds of handling of "fields". Zsh could notice
when it has copied non-white white non-white into the last parameter,
and choose not to strip trailing whitespace in that case, but that's a
complication of the copying algorithm that isn't strictly required by
the specification (such as it is).
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author