From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27272 invoked by alias); 7 Sep 2016 22:07:54 -0000 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-Seq: 39230 Received: (qmail 9725 invoked from network); 7 Sep 2016 22:07:54 -0000 X-Qmail-Scanner-Diagnostics: from out4-smtp.messagingengine.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(66.111.4.28):SA:0(0.0/5.0):. Processed in 0.705159 secs); 07 Sep 2016 22:07:54 -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.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=SUTDYvM8RstXE602 oVcAINc3va8=; b=TE2MCFqH+ZFdGl3kmyFib/1Mv+91RvAWeYwQcagx4/cQiKfp kDbsCM2zzHuzPy6jPHSPl5c8Ttab8VYYk6wLqxFkkSvu5vySA/y+0Zti4zQi6lcd BMNSJIdNMmvtKOq0d52qYKTT/DszeIHCgHIB8ZgHOwcjx3CoVMO0vU+W5D0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=SUTDYvM8RstXE60 2oVcAINc3va8=; b=o7gWScnXV05sPIOkR8T9uIASB4COlMZ+8V4+72CpYy4o0iN IChGDpsBbR9dWQFdq5d5hEynfOYSCARrErC4Ldu965waqz/HhbjsyW91JNp7GkaK 6k+AffrosNy38YvjOQO8XRwQWVhCrvkNhDauSB6uqkk8A6fhz8MOnsKdVOLQ= X-Sasl-enc: yc3C3uLzIOMGxNn7ar8NvXssU2y7UZgHq+4/cvRMscsG 1473286063 Date: Wed, 7 Sep 2016 22:07:01 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH] _arguments: Escape colons and backslashes in $opt_args unambiguously. Message-ID: <20160907220701.GA7775@fujitsu.shahaf.local2> References: <1473013592-24926-1-git-send-email-danielsh@fujitsu.shahaf.local2> <160907000320.ZM11510@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160907000320.ZM11510@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Wed, Sep 07, 2016 at 00:03:20 -0700: > On Sep 4, 6:26pm, Daniel Shahaf wrote: > } > } Is it okay to refer to NEWS from the manual? > > Are there any other examples of the manual referring directly to the > behavior of previous versions? Yes: CONTINUE_ON_ERROR in zshoptions(1). (And the usage examples under is-at-least, but that doesn't count.) > It's not the kind of thing it's easy to search for, I found that with: . ag -C 3 -G 'yo$' '[345][.][0-9]' Doc/Zsh . which is equivalent to: . grep -C 3 '[345][.][0-9]' Doc/Zsh/**/*yo . where the regexp is designed to catch references to zsh version numbers between 3.0 and the present day. 'ag' is usually packaged as "silver_searcher" in distros. > but I can't think of any, so my inclination would be to drop your > parenthetical Note:. > } In the manual I wrote "See NEWS" even though the pointed-to text is in > } README because (a) NEWS includes README by reference, (b) I doubted > } readers would follow a reference to README in that context. > > I doubt readers will follow a NEWS reference either. If this is > important enough to reference -- which I don't think it is -- then > it's important enough to say it here, not cross-reference somewhere > outside of the regular documentation tree, and certainly it shouldn't > require going to NEWS, finding nothing, and then having to realize > it might be in README. > I'm happy to drop the note entirely, or to drop the reference to NEWS and keep the sentence stating the behaviour difference. > } +ambiguity: if the -x option took two arguments (as in > } + _arguments : -x:foo:${action}:bar:$action > } +), it would be impossible to tell from $opt_args whether the command-line > } +was '-x foo\:bar' or '-x foo\\ bar'. > > Is this example correct? Isn't the actual ambiguity between > [[[ -x foo\:bar ]]] (one arg) and [[[ -x foo bar ]]] (two args)? The example is correct, and the two cases you give are not ambiguous with each other: % echo $ZSH_PATCHLEVEL zsh-5.2-dev-1-335-g831a336 % _f() { local context state state_descr line; typeset -A opt_args; _arguments : -x:foo:-\>state:bar:-\>state2; >/dev/tty { echo; typeset -p opt_args } } % compdef _f f % f -x foo\:bar<^C> typeset -A opt_args=( -x 'foo\\:bar' ) % f -x foo\\ bar<^C> typeset -A opt_args=( -x 'foo\\:bar' ) % f -x foo bar<^C> typeset -A opt_args=( -x foo:bar ) What's happening here is that (a) every colon in the word gets preceded by a backslash, (b) colons are inserted between words. No other transformation happens. Consequently: $BUFFER colons to be escaped? colons inserted? result in ${opt_args[-x]} which character(s) were inserted ======= ===================== ================ ========================= ================================ foo\:bar yes no foo\\:bar second backslash foo\\ bar no yes foo\\:bar colon foo bar no yes foo:bar colon Again, that's before this patch. With this patch the first two cases are subjected to backslash doubling at the same time as colon escaping, so they result in «foo\\\:bar» [the first and third slashes were added] and «foo\\\\:bar» [ditto] respectively. > If I'm wrong, what is it about your explanation that confused me? I don't know. Perhaps you assumed words were joined with backslash-escaped colons. Perhaps you misparsed the phrase «was '-x foo\:bar' or '-x foo\\ bar'». There are three distinct levels of quoting at play here: interactive input quoting, ca_colonlist() quoting, and the English prose quoting, where single quotes were used for the function tt() provides in yodl documents. How might the README text be improved? > There's probably still an ambiguity between [[[ -x foo bar ]]] and > [[[ -x foo -x bar ]]] ... This depends on the spec of -x. If -x takes two mandatory arguments, then the first case should parse as as [opt_args=(-x foo:bar)] and the second one as [opt_args=(-x foo:-x) with 'bar' as a positional argument]. However, if -x is repeatable and takes either one or two arguments — as in «_arguments : '*-x:foo:->foo::bar:->bar'» — then I'd say the command-line in the second case is ambiguous. Good catch. Cheers, Daniel