From: thomas@coldfix.de
To: zsh-workers@zsh.org
Subject: Re: Path with spaces in _canonical_paths
Date: Mon, 21 Nov 2022 11:47:48 +0100 [thread overview]
Message-ID: <cd447ee7-d991-a4fd-c155-ca1b6bb96d72@coldfix.de> (raw)
In-Reply-To: <CAH+w=7ZBYX3-X2AD_iDR6T4Yz8OdA1TE+YeC2qZmHdk+W=VbgA@mail.gmail.com>
> I'm not able to reproduce this using nothing but compinit plus the
> compdef above. I get just one completion, "/tmp/My\ File", regardless
> of whether that file exists or not.
>
> Try this:
>
> debug_canonical_paths () {
> _canonical_paths -N files files /tmp/My\ File
> }
> compdef '_complete_debug debug_canonical_paths' cmd
Thanks for your answer! I can't reproduce with the minimal example
anymore either.
However, I still get similar behaviour by first doing:
sudo ln -s /tmp /foo
And then, same as before (with or without debug, with or without extra
function, with or without -N):
debug_canonical_paths () {
_canonical_paths -N files files /tmp/My\ File
}
compdef '_complete_debug debug_canonical_paths' cmd
cmd <Tab><Tab>
Results in:
/foo/My File
/tmp/My\ File
This is with blank zsh configuration `zsh -f` plus:
autoload -U compinit; compinit
> Pressing TAB then drops a file in /tmp with a debug trace of the
> execution of _canonical_paths. In particular look at which "zstyle"
> lookups are being done and which of those might be causing the extra
> entries. You can also look at the context around elements being added
> to the "matches" array.
The trace shows:
+_canonical_paths_add_paths:19> '(anon)'
[...]
+(anon):3> matches+=( '/tmp/My\ File' )
but later:
+_canonical_paths_add_paths:28> matches+=( '/foo/My File' )
which explains why `compadd -Q` handles those differently. So the
different unintended behaviour seems to appear only in the "alternative"
paths.
I originally encountered this behaviour with a file in
/var/run/media/thomas/ which is symlinked to /media on my system. I get
the same problem with files in /usr/bin/ which has several symlinks
/usr/sbin/, /bin, /sbin on archlinux.
I suspect when I previously also got a similar behaviour with my
original minimal example without the symlink, there might have been
tmpfs remounts or something(?), not sure what has changed, I did reboot
in between.
Best, Thomas
next prev parent reply other threads:[~2022-11-21 10:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 17:41 thomas
2022-11-21 3:57 ` Bart Schaefer
2022-11-21 10:47 ` thomas [this message]
2022-11-21 16:30 ` Bart Schaefer
2022-11-21 17:41 ` Thomas Gläßle
2022-11-21 21:32 ` Bart Schaefer
2022-11-23 14:13 ` Daniel Shahaf
2022-11-23 21:36 ` Bart Schaefer
2022-11-23 22:24 ` Daniel Shahaf
2022-11-23 22:42 ` Bart Schaefer
2022-11-23 23:06 ` Daniel Shahaf
2022-11-23 23:12 ` Bart Schaefer
2022-11-24 0:12 ` Daniel Shahaf
2022-11-24 18:42 ` Bart Schaefer
2022-11-23 23:36 ` Thomas Gläßle
2022-11-23 23:40 ` Thomas Gläßle
2022-11-24 18:51 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd447ee7-d991-a4fd-c155-ca1b6bb96d72@coldfix.de \
--to=thomas@coldfix.de \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).