From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9858 invoked by alias); 13 Dec 2016 01:01:20 -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: 40169 Received: (qmail 14937 invoked from network); 13 Dec 2016 01:01:20 -0000 X-Qmail-Scanner-Diagnostics: from nm36-vm3.bullet.mail.ir2.yahoo.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(212.82.97.135):SA:0(0.0/5.0):. Processed in 2.185196 secs); 13 Dec 2016 01:01:20 -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=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 212.82.97.135 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1481590446; bh=5CySOCwScvZbBzZY1Wqm4FFUDWkxXTwpu4EZ6jMiGzo=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=beqDR8TCbR6BAVKOLmxmhUsSLlnPvE/pTwUdN9y7kQCDZbafNBqhRQoGd4hvSxdwTef1ExzAXhOiLhCLbICmqqIIBKpqtdgkm4SHkCtTFx1Lwj0VZ/no6RLjWvl1JO+64yiT/mGBhr1wmBX6ePM+wOmAnMs+oR5vlda3xiphipUaU3pmZvcjJylQ0oUygC7WHo7eBsa4WC/CxP0hGcCNxoNf4WH+4BYekDsTJKxQjRQ+WeKNMzLV+q/c0Do31flHb89A4PKz3TvQiEjQF21z0xP81VLDVPAMlgO7pRc6H7j18V1J67IRKMAo9lPgLsGqd89r4T6bjn2N2Nrw+kO0MA== X-Yahoo-Newman-Id: 566173.54081.bm@smtp142.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9TlFd0wVM1l4GKDQsDebSLUuuGgzY7uIUgl8FBexFABPd0O W1XnLNvC5ac7F3PEkUYbZ_fFMkHUO5wAEkWoLVUmfWPFJnooRnkEf2PtV6Z6 Im4Cwr24f1G7YgLwrOh3vydlO_IwoHH01bQXzxV_NZeVHrj3krywRwLXNgXX NEldOTAQyd_B0SaZ8mGeCpWFrLsSEP.4rBeBaL5.LYH3CHuU1JCGeeU2WT_t Je3cPsGegtcBLdYMhn6vUCvkgnnUliwzm28baYA2J_KopCuwZTIk5KKponsv M2zNXGWHHxW_4zK7TaMoF1F4_B8uapFwJfwxE1c.gY96f5yTHcb04Mzu9aRJ m88DNqrNhVZ_5AayzcN4P7YHz61LltLjtU.sMMgmaU_duQ9rOCuwnNyj5byM .bhaFDJz2GrRUlgueVXzW5nKmEHnWKB9GLb9M2QKz3DAYsPduXCs9OXfSEgq fCo8LLQgr9zYOlEqN9Quw6a_v.wRmVrfdVahpvYr71TXQNP6MPxMlALp6zTb bjOfIe6oEyHgAq8OHH28eFp31WndVaIdhX6IKj4sg X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: <20161212052803.GA53519@CptOrmolo.darkstar> From: Oliver Kiddle References: <20161212052803.GA53519@CptOrmolo.darkstar> To: zsh-workers@zsh.org Subject: Re: _os_arguments MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68783.1481590445.1@hydra.kiddle.eu> Date: Tue, 13 Dec 2016 01:54:05 +0100 Message-ID: <68784.1481590445@hydra.kiddle.eu> Matthew Martin wrote: > When updating completions for the BSDs, it can be a bit of a pain to > check each case or if block especially since the alphabetization of the > options is disrupted. This is an attempt to ease that pain. First an > example usage converting _rm to _os_arguments then the patch itself. Have you seen the approach taken in _chown, _cp, _du and _last which also does not disrupt the order of options? There could be ways to compress the patterns down. Having only a single letter and wrapping _arguments directly means that this wouldn't work for a number of functions. We have quite a few cases where we do: _pick_variant -r variant gnu=GNU $OSTYPE --version and then use $variant with the case statement. Also, there are quite a few cases where we include the version number, particularly with Solaris because Solaris 10 still gets a fair amount of use (is still the primary platform where I work). I was planning to do this somewhat more in future for BSDs (at least at major version level) now that we've got more of the functions in a good state: it's easier when adding them incrementally. Rather than wrap _arguments directly, it might be more flexible to have some sort of filter_args helper. That could also be applied around _values too for, e.g. dd or ifconfig. It could allow for custom letter mappings and have the option of making other transformations on the args list before going on to _arguments. It might also be easier to mix with _arguments' sets feature. Long options can pose a bigger challenge when trying to handle different systems. There are a few GNU utilities such as grep where FreeBSD and Darwin have forked at the final GPL2 release. So I can see there being more cases where we need to handle these with associated issues such as sharing the latter part of the _arguments spec (description etc) between the long and short option. I'd regard alphabetization of options to be a lesser concern. For single implementation commands, I try to follow the ordering from -h / --help output which is usually a mix of logical, alphabetical and some randomness. And sometimes it'd be more helpful to have them ordered with options that have similar mutual exclusions. > +case $OSTYPE in > + aix*) os=A;; > + cygwin*) os=C;; Note that this case statement could be done as an associative array. I mention this mainly because an associative array is easier to extend if we were to support that: typeset -A osabbrev osabbrev=( 'linux*' L 'openbsd*' O ..... ) os=${a[(k)$OSTYPE]} Oliver