From: ZyX <kp-pav@yandex.ru>
To: "Ray Andrews" <rayandrews@eastlink.ca>,
"Lawrence Velázquez" <larryv@macports.org>
Cc: "zsh-users@zsh.org" <zsh-users@zsh.org>
Subject: Re: surprise with echo
Date: Sat, 20 Dec 2014 12:45:36 +0300 [thread overview]
Message-ID: <1163791419068736@web17g.yandex.ru> (raw)
In-Reply-To: <54950B02.3010907@eastlink.ca>
20.12.2014, 08:39, "Ray Andrews" <rayandrews@eastlink.ca>:
> On 12/19/2014 09:08 PM, Lawrence Velázquez wrote:
>> You still don't understand what's going on. The expansion only results
>> in a null result *if the array itself is empty*. Null *elements* do
>> not produce the same behavior.
>
> Yes, I understand it, I just spoke poorly.
>> Agreed. That's why enabling RC_EXPAND_PARAM by default should never
>> happen.
>
> I'd say that if it worked the way Kurtis showed that it's 'supposed' to work
> then that would be the best of all possible worlds. But it's just my 1/2
> cent, I don't value my own opinion on this beyond that.
>>> OTOH Bart just showed how the surprise can be avoided so ....
>> It's only a surprise if you enable the option without understanding
>
> what it does first.
>
> Too true.
>> clang -I${include_dirs} test.c What would be the point of this
>
> expanding to "clang -I test.c"? It seems entirely reasonable to drop
> that word entirely and expand to "clang test.c", which is what actually
> happens. vq
> Well, whatever more experienced people think. I have no skin in the
> issue, but my intuitive sense of it is than a 'nothing' should just be
> nothing, but it shouldn't go killing things that are not nothing. It's
> probably not debatable, and it doesn't matter anyway. Especially if
> there are other examples of that sort of thing, then it might not be
> considered a surprise. But if that's the only place where it happens,
> then I'd say it's questionable. That expansion is sure cool, but I don't
> think it should kill entire strings: echo "what's wrong with this
> string? $@", especially since it leaves it alone if we use " $* ".
> Dunno. All I can say is that rc itself seems to agree with me.
When thinking about RC_EXPAND_PARAM I think of it as applying `map` to an array that prepends/appends strings. As such `-I${include_dirs}` with empty $include_dirs does not kill an a string. It just transforms an empty array to an empty array and that’s all. You don’t think that e.g. `map(lambda v: '-I' + v, lst)` (Python) should produce `['-I']` for the empty list, do you?
I though use $^ and not RC_EXPAND_PARAM in which case it is clear that an array is treated specially. It also does not work inside `""` which makes it even more clear. If RC_EXPAND_PARAM was on always I would find it logical, but unexpected and not convenient.
next prev parent reply other threads:[~2014-12-20 9:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 1:24 Ray Andrews
2014-12-19 3:06 ` Bart Schaefer
2014-12-19 3:20 ` Lawrence Velázquez
2014-12-19 6:09 ` Ray Andrews
2014-12-19 6:30 ` Kurtis Rader
2014-12-19 17:54 ` Ray Andrews
2014-12-19 4:14 ` Kurtis Rader
2014-12-19 4:39 ` Lawrence Velázquez
2014-12-19 5:19 ` Kurtis Rader
2014-12-19 6:00 ` Lawrence Velázquez
2014-12-19 5:57 ` Bart Schaefer
2014-12-19 6:08 ` Kurtis Rader
2014-12-19 6:58 ` Ray Andrews
2014-12-20 2:55 ` Bart Schaefer
2014-12-20 3:05 ` Kurtis Rader
2014-12-20 3:49 ` Ray Andrews
2014-12-20 4:40 ` Bart Schaefer
2014-12-20 5:50 ` Ray Andrews
2014-12-19 6:45 ` Ray Andrews
2014-12-19 11:21 ` Oliver Kiddle
2014-12-20 2:09 ` Bart Schaefer
2014-12-20 2:58 ` Kurtis Rader
2014-12-20 3:55 ` Ray Andrews
2014-12-20 5:08 ` Lawrence Velázquez
2014-12-20 5:37 ` Ray Andrews
2014-12-20 9:45 ` ZyX [this message]
2014-12-19 6:00 ` Ray Andrews
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1163791419068736@web17g.yandex.ru \
--to=kp-pav@yandex.ru \
--cc=larryv@macports.org \
--cc=rayandrews@eastlink.ca \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).