From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15276 invoked by alias); 31 Oct 2016 07:47:19 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22050 Received: (qmail 14141 invoked from network); 31 Oct 2016 07:47:19 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f46.google.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(209.85.213.46):SA:0(0.0/5.0):. Processed in 0.85319 secs); 31 Oct 2016 07:47:19 -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=SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.46 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=kMiJSVi/fO849Z1qdnZgR9TtQWXawlkor4TPdNbjV3I=; b=fc1W45XjI+6RQGrBG4mgOKP65j65M3fvJWNCbho/YF/Osf+iLrSwIzF0WexATG9aY9 0VfyEyANAcVZ8Truy5ZFj6oK1z35+QMeXCeaYMdpmSktsEbO2MHCM8dcShneEutlJfWj t5IHQs8F2h5CgN/IsJ4kbRm4l6+93K5t+8c1PD/ERcxZZPwU4DTCVEr3exn+D7xsUJ7e LUrDFMiwh/SlYY+nIfmwqP2LS+xmWjsi39FVcWUkPHI5J2Eap2fIxT65BtkzPAcpjKbx Ilfu5rIOiOoDf8FO+AxGluamIMc9A+0EQvgceNqBhuqz0ELi/86NIDbSlmLRzSMqWaAr lBXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=kMiJSVi/fO849Z1qdnZgR9TtQWXawlkor4TPdNbjV3I=; b=GRFBN1K9wdkmonxfmZ4cp5KUd8VrM/9Rwz4fMD8RF1JKOAjCB0iAGqiev3ZVJr8zNs LR1ZAj/oj6xndeKbmNcXliBjL5ppORJH9NWipPfPXBnTU1Klhp91OO/ypXI7XvgLGvao Wr/2RsCcx3v27MqhGAMbCE271lw/+wejH00zvJ/mjwthV/fscisoJt+bTILQ6GUyvEt3 xAN0wVifg0gILSLdgJHKoI2S4YiPtJWdp5bkHLGPn+57WA8gElWVyrr8hvnJFYhYRDXg cJPillGa6AxNDl/thPoANqAzLnkfltWeBq95vvNbu6N4O62fqIREW5zcNaBW78ZDhant 2czw== X-Gm-Message-State: ABUngvfshqkAIX91qUFtZui/vb8edjxNPITsPG6cURdKwME5AWzDK1II2MKFPnlnjL2+5Q== X-Received: by 10.31.59.1 with SMTP id i1mr22459972vka.115.1477900031018; Mon, 31 Oct 2016 00:47:11 -0700 (PDT) From: Bart Schaefer Message-Id: <161031004732.ZM18486@torch.brasslantern.com> Date: Mon, 31 Oct 2016 00:47:32 -0700 In-Reply-To: <58164C21.9090505@gmx.ch> Comments: In reply to Fourhundred Thecat <400thecat@gmx.ch> "Re: zsh completion for umount" (Oct 30, 8:38pm) References: <5815DDAB.8070307__40712.3355348178$1477828401$gmane$org@gmx.ch> <20161030153537.GB12137@fujitsu.shahaf.local2> <58164C21.9090505@gmx.ch> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: zsh completion for umount MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 30, 8:38pm, Fourhundred Thecat wrote: } } When I remove everything from .zshrc, and only leave following two lines: } } autoload -Uz compinit } compinit -D } } then completion for mount -o starts working, same as you describe. } That is great progress. But umount m still does not complete, nor } does umount ./m Curious that no one has noticed this before. Completion for mount / umount works fine as long as you're completing full paths, either to device files or to mount points. However, the _canonical_paths function that's used to convert strings on the command line into the One True Path to either such a device or mount point, is somewhat deficient when it tries to compare a relative path to the canonical path, as is necessary to complete the path tail when the current directory is already part of the canonical path. I don't have any more time to chase this now, but briefly in case someone else wants to pick it up: "_canonical_paths_add_path $PREFIX" is called which, if prefix is not empty, tries calling zstat to see if it is a real file. Of course this fails because it's not a file, it's only a prefix of a filename, so _canonical_paths_get_canonical_path is NOT called, and the path from the current directory is not discovered. The upshot is that _canonical_paths_add_path only does anything useful if the prefix on the command line is either already a device or mountpoint, or is the name of a directory in the partial path to one. If you try to trick it as Daniel suggested by adding "./", things are only slightly better in _canonical_paths, but then go sideways later: the bug discussed earlier this year, in which the current prefix is erased but nothing replaces it, affects this completion.