From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4177 invoked from network); 14 Aug 2000 08:32:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Aug 2000 08:32:14 -0000 Received: (qmail 4119 invoked by alias); 14 Aug 2000 08:31:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12611 Received: (qmail 4111 invoked from network); 14 Aug 2000 08:31:52 -0000 From: "Bart Schaefer" Message-Id: <1000814082830.ZM22494@candle.brasslantern.com> Date: Mon, 14 Aug 2000 08:28:29 +0000 In-Reply-To: <001001c005c1$c6847390$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "What's wrong with 12500?" (Aug 14, 11:32am) References: <001001c005c1$c6847390$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: "Andrej Borsenkow" , "ZSH workers mailing list" Subject: Re: What's wrong with 12500? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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