zsh-users
 help / color / mirror / code / Atom feed
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.


  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).