From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21095 invoked by alias); 6 Sep 2016 23:38:35 -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: 39198 Received: (qmail 4343 invoked from network); 6 Sep 2016 23:38:35 -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.502567 secs); 06 Sep 2016 23:38:35 -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=cc: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=yk532qAZz7/P3tC7 nJDuTzFq/sk=; b=HyloKNCy2R2VJS+JtcZPjr97kbWtXiD0U7YCHdiNQ6LLGAjZ Ft0O5Xhg4utkjZXopcPmEzzOtP6SGdJ1kKkSjrmVZnrLeZTnj6QIsZX2lkzMCCR6 EiCT+/4ZCWvV3y8mQLNef08eTSi7veO78vm5aNHybzuzTjhVFII9IXbhuh8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=yk532qAZz7/P3tC 7nJDuTzFq/sk=; b=JEVmTq1CpEO53sMw/A85xFG4vVzJ/zTUq9hZ959JlbWVKWP OLIuQS6BvlXGBLkIQ88MrSBejiTSeWi026i+AXTNCrRhZ0JH5KCTh3zMKdeZGEYV Zk1C3DCGQm2ciVzEQs/XOZlfqXcv4CDBKwAXbwlYB/tCAh5CzQoV33siMQ8Y= X-Sasl-enc: r84rMjY8mm9Q30Fup1VH3O4yzD+fQKmxP2O3M8dHf1CC 1473205110 Date: Tue, 6 Sep 2016 23:37:51 +0000 From: Daniel Shahaf To: Marko Myllynen Cc: zsh workers Subject: Re: Zsh OpenStack completions Message-ID: <20160906233751.GA17896@fujitsu.shahaf.local2> References: <9361ff20-f0f2-9acd-e43e-4b1e2e203531@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9361ff20-f0f2-9acd-e43e-4b1e2e203531@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Marko Myllynen wrote on Tue, Sep 06, 2016 at 15:39:02 +0300: > Hi, > > Below is a patch to add completions for several OpenStack related > command line clients, including the new common client, openstack(1). > > There are three categories of clients: > > 1) newer clients which provide per-command sub-commands and options > 2) old skool clients which provide the "bash-completion" command > 3) an oddball, swift, slightly different than 2) It would be useful to have this information in a comment above the declaration of the corresponding arrays. More generally: having block-level comments would be useful. See for example the computil.c part of 39173. Without them the code would be harder to work on in the future. > We cache things pretty aggressively as something like "neutron help" > takes ~0.75s on my laptop (compared to 0.002 of "ls --help") and > openstack(1) even goes over the network for the list of completions. A brilliant example of the pendulum tendency to take us all back to the dumb terminals era of the 70's :-) > (Also, searching for (sub)commands from the associative > array doesn't look very nice but I'm not sure how to do that better > while still making sure that e.g. net-list and net-list-on-dhcp-agent > are not being confused - perhaps I missed a flag to aid in this.) I assume you refer to this line? — for word in ${words:1}; do [[ $_cache_openstack_clnt_cmds[$service] != ${${${_cache_openstack_clnt_cmds[$service]#$word }% $word}/ $word } ]] && cmd=$word && break done You could get around the triple % # / check by adding a space before and after the string, i.e., let the associative array's value be " foo bar baz " and then just grep for " foo " (with the spaces). Or you could use the (w) flag: . % s="foo foobar" % print -r -- $s[(wI)foo] 1 % print -r -- $s[(wI)bar] 0 Or you could call use a different variable name for each command, i.e., «typeset -a _cache_openstack_magnum_subcommands» and so on. You'd then use the (P) parameter expansion flag to access the variable: . cachevar=_cache_openstack_${service}_subcommands typeset -a $cachevar print -rl -- ${(P)cachevar} compadd -a -- $cachevar You may also need to change ${word} to ${(b)word} inside the condition to prevent $word from being interpreted as a pattern. I know I said that [offlist] above virsh too, I haven't made the change there yet but I think I will later. > There's one case which I'm not sure there's a perfect solution without > hard-coding / special-casing lots of commands/options: some commands > of some clients accept some options more than once - for example, for > "openstack project create" the "--property" option could be repeated > (to provide several key=value pairs). I'm not sure what's the problem here: whether it's needing to write code to permit select options to be specified multiple times or having to enumerate all options that may be multiply-specified. If it's the former: _arguments solves that for you: . _f() _arguments : '*-x:foo:_hosts' compdef _f f f -x bar - If it's the latter: the alternative to hardcoding a list would be to parse that information from the --help or --completion output. This may mean getting openstack upstream to emit that information therein. (Tangentially: I wish there were a standard format for parseable help; basically a variation of --help that emitted information that (a) were machine parseable, (b) could be compiled into a zsh completion function.) > So if trying to stay generic, > we'd need to accept several options in all cases (which is mostly > incorrect) or accept options only once and force the user to type > the option if wanted more than once. I've chosen the latter as > it would seem that in most cases there's some typing needed anyway > for repetitive options (like key=value pairs, DNS servers, IP > addresses, etc), so while not perfect this doesn't strike me too > cumbersome. > --- > Completion/Unix/Command/_openstack | 136 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 136 insertions(+) > create mode 100644 Completion/Unix/Command/_openstack I'll go through the diff later. Cheers, Daniel