From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13215 invoked by alias); 20 Dec 2014 09:45:42 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19624 Received: (qmail 18116 invoked from network); 20 Dec 2014 09:45:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_FSL_HELO_BARE_IP_2 autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1419068737; bh=MjS6c9dsqL6bCLSOZYFnL0ij3OD8Ji/LoMizgj30fAE=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=pDHGuV8CnAsbYnXto+FGSK864Dr9dJXKDQMpB8mkseYQqXPN40uXx/o3UFQd2XMsY Ec1YslXfWU6rGyYy3e3KB/oNehp7iqhoc7prOinZcxTT2ijNgX2zc+fjEd6yX9Fn6Q iWR1+89O05qodjoukUoZ4d9+r+cBlqkISdrY9ozk= From: ZyX To: Ray Andrews , =?utf-8?B?TGF3cmVuY2UgVmVsw6F6cXVleg==?= Cc: "zsh-users@zsh.org" In-Reply-To: <54950B02.3010907@eastlink.ca> References: <54937E5B.2020008@eastlink.ca> <141218190653.ZM16331@torch.brasslantern.com> <20335.1418988086@thecus.kiddle.eu> <5494F332.7000008@eastlink.ca> <54950B02.3010907@eastlink.ca> Subject: Re: surprise with echo MIME-Version: 1.0 Message-Id: <1163791419068736@web17g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 20 Dec 2014 12:45:36 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 20.12.2014, 08:39, "Ray Andrews" : > 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.