From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20212 invoked by alias); 4 Jan 2018 11:47:44 -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: List-Unsubscribe: X-Seq: 42218 Received: (qmail 10468 invoked by uid 1010); 4 Jan 2018 11:47:44 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net 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(205.235.26.22):SA:0(-1.4/5.0):. Processed in 9.781825 secs); 04 Jan 2018 11:47:44 -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=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, SPF_PASS,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=Plqy=D7=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1515066438; bh=7WRcHTEdELQJMtmpDucV8myTssQ3JLxG0QTMyQI61rk=; h=From:References:To:Subject:Date:From:Subject; b=OWp9goGEXP3GJWocmGmfa6K1Kmh9fAnhLrsgqP/wyghCzOQJ0YHwkHz+3De3xfljRr79vLFzWWGqd7bO4y2KqubV+D2IWu4Fgnjipq5Gv+deicKJlviIdJ1HrV1DnDkdhiIv/8xiSlL7moCV4WvkcWqX6Aoh9ayUObIcT0lgc2Ai01aEysz+phamu9jbgqnCiaGBdpXv0tP+pOMMO/CLYNkw+myiOv383zdmrbAEu6TnI5hT6bnpVMt/AZ4u6PWEnCsRUT58TWYBuObRBny0uuQ8NVw93zyhmrlX6MgzncvHPA+eHbrHz2bPUA4d8CkN4Nce8OudCKTvYy1ndwiN0w== X-YMail-OSG: i3VrzxoVM1lUfffmV4eoYJd1bff.QDr5TSSp2rogZcrgM7njK1ZBMlg2D4HPGLL ps9TB6bOcvFea9_1a62ISkL1bbb2aCyO4uUNVj7Oi8KtnGVStX_i0WHqiwObXzzJb9iCBy4LqFE_ MW3uM8JSzx_h1A22OwwJVr.P2fJZ133oCFV0nR7VU_z33HKjXE59sNSU7wanr3gHA7Iw_dT.j.AW Bz6hAoF.WR1L2hKeAxg0rNB_XWylJHmCB_7T68_B_nzkTpG9Z9fLO4mcvXA1U.kmvE4d2P6DAL0y J4UJeq8Kuj6wk_H2TJ3d6r07FpXpHU7QS5ok1ZbM8A.9HLZxoRmDgFf9ViU42IY84nnMG24YEdWs ALEcmDsAoScGyEwaHv5dnDxTWkdfLzef1gBhCK69X_UvLl12JCwFMiSYt6R.5pEJE_KTajfe88FA uwQIgJsYNg.I8X51.x919Xq_ZtMbbEhcrx_gyYfqCHGh3PDFUPjyzRvq5KB1C7GwF9kJdqO8v5GB 4g8QWeRaha860 cc: zsh-workers@zsh.org In-reply-to: <1C17F1B9-C935-44B0-A8E4-52D87EE76DE6@dana.is> From: Oliver Kiddle References: <289FC0FD-FDAB-4575-8882-E9F8F3FFE4C5@dana.is> <18174.1515022825@thecus.kiddle.eu> <1C17F1B9-C935-44B0-A8E4-52D87EE76DE6@dana.is> To: dana Subject: Re: [PATCH] Completion batch #2: Misc. trivial fixes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20805.1515066433.1@thecus.kiddle.eu> Date: Thu, 04 Jan 2018 12:47:13 +0100 Message-ID: <20806.1515066433@thecus.kiddle.eu> dana's message doesn't seem to have come through on the mailing list so I'll quote generously. dana wrote: > >Digging around in $_cmd_variant is essentially looking into the > >internals of _pick_variant. The documented interface is to use the -r > >option to _pick_variant. Also, it is not saving the full output of > >expand --version, it will either have the value "gnu" or "unix". > > Well, maybe it's worth bringing this up now, then, before i submit any further > patches: The reason i'd added that check is that i wanted to be able to complete > commands like this: > > % busybox expand - > > This use case doesn't seem (necessarily) compatible with _pick_variant as-is, > because your unadorned `expand` may be a totally different variant from `busybox > expand`. The way i had handled this in the _busybox function is: > > _cmd_variant[${words[1]}]=busybox _normal > > That way you can temporarily override what _pick_variant thinks the actual > variant is. This seems to work quite well, but i did feel some guilt about it, > since as you mention it's circumventing the interface. Given that that works well, I'd go with that solution. It'd be possible to add an option to _normal/_dispatch. Having them know about _pick_variant internals is less ugly. It is, however, probably only worthwhile if it is going to be used elsewhere. It might be wise to dig around for other use cases. _builtin is the only thing that comes to mind. > Another issue i had with _pick_variant is dealing with risky commands. In most > cases i imagine it's probably fine to do something like `poweroff --help`... but > i certainly didn't want to take the chance, since a badly written poweroff might > just kill the machine if you're running as root. So i had again bypassed > _pick_variant and manipulated _cmd_variant myself. Yes, we don't want to ever call risky commands or commands that might have side-effects. For poweroff, just don't use _pick_variant. Rely on $OSTYPE and other tests like [[ -d /etc/systemd ]]. Caching the result is unlikely to be necessary but if it is, don't use _cmd_variant. poweroff likely doesn't get run many times in a single zsh session anyway. > Do you have a suggestion as to how i could accomplish things like this in a less > hacky way? Maybe _pick_variant could learn an option to set the variant > directly? Alternatively, maybe i am over-engineering everything again...? > > On 3 Jan 2018, at 17:40, Oliver Kiddle wrote: > >Given that these are hidden options, excluding other numeric options is > >pointless. It is also arguably wrong because the tab width can be more > >than 9 characters wide: e.g. expand -20 is valid. > > All i really wanted was to have it not offer -t if a numeric option's already > been given. The completion function doesn't have to know that -20 is different > from -2 -0 to do that, AFAIK. Didn't consider that excluding the other options > is pointless though, i suppose it is superfluous. Doesn't "superfluous" have much the same meaning as "pointless" in this case. It seems to work as it is but I'd clean it up if making changes for the busybox variant anyway. Doesn't busybox allow expand to be a hard link to busybox to run expand? I've applied the rename patch by the way. Bart makes a good point and I also prefer _file_modes to _fmodes. Oliver