Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Qmail-Scanner-Diagnostics: from mailout3.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.13):SA:0(-0.5/5.0):. Processed in 0.194714 secs); 11 Aug 2016 10:05:57 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f4-f796c6d000001486-1a-57ac4dfcfed3 Date: Thu, 11 Aug 2016 11:05:45 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: [bug] shwordsplit not working on $@ when $# > 1 Message-id: <20160811110545.1b066d2f@pwslap01u.europe.root.pri> In-reply-to: <160810102836.ZM15324@torch.brasslantern.com> References: <20160808111626.GA19766@chaz.gmail.com> <20160808192734.21923640@ntlworld.com> <160808182124.ZM9355@torch.brasslantern.com> <20160809094013.01f0f5f8@pwslap01u.europe.root.pri> <160810102836.ZM15324@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsVy+t/xq7p/fNeEG3z8Y2FxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4MiYv/clecEq4Yvmxe2wNjLv4uxg5OSQETCTW/7/HCGGLSVy4 t56ti5GLQ0hgKaPExw9XGCGcGUwSn/e1skM45xglrm3fxQzSIiRwllGiaaMgiM0ioCqx8NNP dhCbTcBQYuqm2WBjRQTEJc6uPc8CYgsL2Eh0nZsHFucVsJfY9+kUE4jNKWAlMW/qVHaImR8Z JTpaRUFsfgF9iat/PzFBnGcvMfPKGaheQYkfk++BzWQW0JLYvK2JFcKWl9i85i3UbeoSN+7u Zp/AKDwLScssJC2zkLQsYGRexSiaWppcUJyUnmuoV5yYW1yal66XnJ+7iRESzl92MC4+ZnWI UYCDUYmH90Pa6nAh1sSy4srcQ4wSHMxKIrwPfdaEC/GmJFZWpRblxxeV5qQWH2KU5mBREued u+t9iJBAemJJanZqakFqEUyWiYNTqoGR51XZor2fmY336X47tqGW/2KL+a6nkhczn6yK0Pn9 Kr2ne82vXvW7Tj82ftv6/P5fhjreNlbhjDN74pITQkVSNjOG/s1o4Ny8qGVFreT2fb9WLlu+ 69Y5gcbslweCI+sOz1J+HVj+dt3clf3HF7vefT71e5DvtcKssK++JhfflmjscxN7srNyhxJL cUaioRZzUXEiAOb2xmhjAgAA X-Seq: zsh-workers 39021 On Wed, 10 Aug 2016 10:28:36 -0700 Bart Schaefer wrote: > torch% x=(a:b "c d" ef) > torch% print -l ${(s.:.)x} > a > b c d ef That's correct, that's forced joining, which is documented. As I said in my previous email, it's not clear it's actually a lot of use. > torch% print -l ${(@s.:.)x} > a:b > c d > ef > > The second one used to work exactly like the first one, > and is the one that worries me the most. I think it should only cause a visible effect in double quotes as that's its real point --- though I wouldn't be surprised if there were already exceptions. It's hard to see how it could be interpreted to mean ignore the (s.:.), even if there are double quotes. You might also hope that logically this would have the same effect as ${(s.:.)@} when the contents of $@ were the same as the contents of $x, regardless of context (i.e. whether or not in double quotes). Possibly that conflicts with the principle that it has no effect outside double quotes, but I can't think of a case. To be clear: it is not a conflict that SHWORDSPLIT behaviour and (s...) behaviour differ from one another, e.g. with respect to forced joinging, only if expressions involving the same modifications to ${(@)x} and $@ differ when the contents of the arrays and the contexts are the same. Note the documented oddity of the behaviour of (s...) in double quotes when (@) does *not* also appear. But as far as I know the combination of the two has always behaved rationally by zsh standards. > Then there's this weird edge case, where an empty $IFS acts like you > have specified the (@) flag when shwordsplit is set: > > torch% IFS= > torch% setopt shwordsplit > torch% print -l ${(s.:.)x} > a:b > c d > ef Hmm... I would guess that what's happened is without an IFS forced joining with a default separator fails, and because it didn't get joined we refuse to split it (I think there was a sort of vague assumption at one time that it only made sense to split a scalar into an array, rather than an array into multiple arrays, though there are obviously exceptions so this isn't much use as a rule). That's probably a bug --- I would think the most logical answer here is it should have been joined with no separator and then split, but I doubt this has ever been thought about before. I wouldn't expect SHWORDSPLIT to make a difference if forced splitting is in use, but that's another cavalier statement. pws