From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21022 invoked by alias); 19 Dec 2014 04:15:02 -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: 19585 Received: (qmail 5855 invoked from network); 19 Dec 2014 04:14:59 -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.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p7RtfZCPxKN7TqheXkAKEoTQyg3FnqZBompk2JmN7Lw=; b=GfGwQeLUhOatUfkBlTnqM26OmoUMkrrZ+rYae3U7MiHgUcS/8AljWZOZBQL2dpouKN 47S/v5pqQjfCoa2fkdsdnXXnm1KJvrLxAGbSUQVo3FjD9dLECdehps2cS/9hpOhQErKM bkcqzhKyqXTO6Byk67Y+AjckUtPAbY9arSJH+AXZ4cr95Gwb4o4eJjrQT7RXUWlSl/e5 TGoYzRKd8GW3M2DNeEmMciPoF6MaQEkk2B9i1zdFmtq17yvN9mkgt9Ty/UiZtE8KiPbX 8ya41R/Q+V+JvlEuAQDVstqHu+mHvSoImvg0De1yRFNtF4CsRQJSV+vqnnm2NaH+oKQR Je5Q== X-Gm-Message-State: ALoCoQkj4xWZvsVOPqq6Q05eoP8JCn/qv6QV4Gz+E7ZxejmpW51rS5p5it5OOCc5oRRwc5LysTJP MIME-Version: 1.0 X-Received: by 10.112.181.106 with SMTP id dv10mr944256lbc.88.1418962493809; Thu, 18 Dec 2014 20:14:53 -0800 (PST) In-Reply-To: <141218190653.ZM16331@torch.brasslantern.com> References: <54937E5B.2020008@eastlink.ca> <141218190653.ZM16331@torch.brasslantern.com> Date: Thu, 18 Dec 2014 20:14:53 -0800 Message-ID: Subject: Re: surprise with echo From: Kurtis Rader To: Bart Schaefer , Ray Andrews Cc: Zsh Users Content-Type: multipart/alternative; boundary=001a11c36d4264c42a050a89f36a --001a11c36d4264c42a050a89f36a Content-Type: text/plain; charset=UTF-8 Bart, I don't see how the zsh behavior is compatible with the Plan 9 rc shell. More on that below. Ray, You really do not want to set non-default zsh options related to emulating the behavior of a different shell. If, for example, you want zsh to behave like ksh93, or csh, or the Plan 9 rc shell you're probably better off just using those shells. If you explicitly change the behavior of zsh by setting options you can't reasonably complain unless the resulting behavior contradicts the documentation. Bart, It appears to me that zsh treatment of "setopt rc_expand_param" is *not* consistent with the Plan 9 rc shell. As a grey-beard (I fell in love with UNIX in the 1980's when the C-shell was bleeding edge) I'm familiar with all the major variants of shells and kernels. Thus I was vaguely familiar with Plan 9. Having said that I have only spent a few hours playing with Plan 9 in the distant past when it was bleeding edge. Since this issue intrigued me I did a sudo apt-get install rc on my Ubuntu VM instance. As best I can tell the behavior exhibited by Plan 9 rc shell only applies to explicit string concatenation. And even then it does not cause the resulting string to be completely omitted. It is possible, even likely, I'm missing the point of the RC_EXPAND_PARAM emulation option since I've never used the Plan 9 rc shell before today. If that is true then I would argue the zsh documentation needs to be expanded with examples showing the mapping of rc to zsh constructs that are affected by this option. I created a shell script containing #!/usr/bin/rc echo echoing1: $@ echo echoing2: $* echo echoing3: $* $@ killed echo echoing4: $@ $* dead echo aaa^$*^bbb echo ccc^$@^ddd Then ran it: $ /tmp/x echoing1: echoing2: echoing3: killed echoing4: dead aaabbb cccddd $ /tmp/x A B C echoing1: echoing2: A B C echoing3: A B C killed echoing4: A B C dead aaaAbbb aaaBbbb aaaCbbb cccddd Notice that in the first case the "aaa...bbb" string was not elided. And neither invocation affected the echo statements provided by Ray. I appreciate that zsh is not rc and they have different syntax and semantics (e.g., "$@" does not appear to mean anything in the rc shell). Nonetheless, at a first glance it does appear that the zsh RC_EXPAND_PARAM option behavior is not consistent with the rc shell. On Thu, Dec 18, 2014 at 7:06 PM, Bart Schaefer wrote: > > On Dec 18, 5:24pm, Ray Andrews wrote: > } > } Why should it do that? It's very cool what it permits > } as explained in 'the book' p. 288, but is the above > } part and parcel of that? > > The doc spells this out explicitly: > > RC_EXPAND_PARAM (-P) > Array expansions of the form `FOO${XX}BAR', where the parameter XX > is set to (A B C), are substituted with `FOOABAR FOOBBAR FOOCBAR' > instead of the default `FOOA B CBAR'. Note that an empty array > will therefore cause all arguments to be removed. > > } Can that be prevented? > > Only by turning off the option, or by doing e.g. ${@:-''} so that the > expansion is the empty string rather than the empty array. > > } Is this a feature? > > It's how array expansion works in the "rc" shell, which is the source > from which this behavior is borrowed. There's probably an "rc" list > somewhere where you might get an explanation. > -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank --001a11c36d4264c42a050a89f36a--