* ls completion @ 2024-06-03 16:56 Thomas Lauer 2024-06-03 20:40 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Thomas Lauer @ 2024-06-03 16:56 UTC (permalink / raw) To: Zsh Users Hi all, I very rarely use ls as I have written my own directory lister. So the other day I did use ls for a test and this is what happened when I pressed the <tab> key: 1/usr/share/zsh>ls <tab>drwxr-xr-x 1 root root 80 23/07/15 14:25 ./ ls -<tab>drwxr-xr-x 1 root root 80 23/07/15 14:25 ./ ls - ./<tab>drwxr-xr-x 1 root root 80 23/07/15 14:25 ./ All text after the three <tab>s to EOL is completion output. For other commands like cp or awk etc completion works as expected. <tab> is bound to expand-or-complete-prefix. I have no alias or function called ls. The _ls in /usr/share/zsh/functions/Completion/Unix/ is as far as I can tell the one that came with zsh v 5.9. At least I've not modified or replaced it. 1/usr/share/zsh/funct/Compl/Unix>zsh --version zsh 5.9 (x86_64-debian-linux-gnu) 1/usr/share/zsh/funct/Compl/Unix>d _ls Dir: /usr/share/zsh/functions/Completion/Unix (overlay mounted on /) -rw-r--r--# 9206 05.02.23 01:37 _ls 1 file(s)= 9206 using 9216 ; 0 DOTfile(s); 0 dir(s) 0 symlink dir(s); 15919M2 of 17249M0 free on / I assume that *something* in my zsh config must be the culprit but I've not the faintest what that could be!? As ever thanks for any hints. Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ls completion 2024-06-03 16:56 ls completion Thomas Lauer @ 2024-06-03 20:40 ` Bart Schaefer 2024-06-04 12:34 ` Thomas Lauer 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2024-06-03 20:40 UTC (permalink / raw) To: Thomas Lauer; +Cc: Zsh Users [-- Attachment #1: Type: text/plain, Size: 755 bytes --] On Mon, Jun 3, 2024 at 9:57 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > <tab> is bound to expand-or-complete-prefix. I have no alias or function > called ls. The _ls in /usr/share/zsh/functions/Completion/Unix/ is as > far as I can tell the one that came with zsh v 5.9. At least I've not > modified or replaced it. > > I assume that *something* in my zsh config must be the culprit but I've > not the faintest what that could be!? > Type Ctrl+x ? instead of TAB, to invoke _complete_debug, then examine the output file to see what's being done. One possibility is that "ls --help" called by _call_program from _pick_variant (to initialize the options known to the local version of "ls") is producing some unexpected result. [-- Attachment #2: Type: text/html, Size: 1126 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ls completion 2024-06-03 20:40 ` Bart Schaefer @ 2024-06-04 12:34 ` Thomas Lauer 2024-06-04 13:19 ` zeurkous 0 siblings, 1 reply; 5+ messages in thread From: Thomas Lauer @ 2024-06-04 12:34 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users From: Bart Schaefer <schaefer@brasslantern.com> Date: Mon, 3 Jun 2024 13:40:50 -0700 > Type Ctrl+x ? instead of TAB, to invoke _complete_debug Ctrl-x ? does nothing here as I have completely redefined all the bindings but I've now put that on Alt-i. Thanks for that, could come in handy one of those days. > then examine the output file to see what's being done. Mea culpa :-/ I've checked whether there's an alias, function, script etc etc called ls. But I haven't checked for _ls... and there's a tiny helper function for ls I've hacked together very shortly after installing zsh... and this derails the completion. (Nowadays I call these helpers ls0, or ls00, but back then I was a complete 100% newbie whereas today I am just a 98% newbie... Big progress :-) ). Again thanks Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Re: ls completion 2024-06-04 12:34 ` Thomas Lauer @ 2024-06-04 13:19 ` zeurkous 2024-06-04 14:09 ` FU: " zeurkous 0 siblings, 1 reply; 5+ messages in thread From: zeurkous @ 2024-06-04 13:19 UTC (permalink / raw) To: Thomas Lauer, Bart Schaefer; +Cc: Zsh Users Haai, On Tue, 04 Jun 2024 13:34:54 +0100, Thomas Lauer <thomas.lauer@virgin.net> wrote: > (Nowadays I call these helpers ls0, or ls00, but back then I was a > complete 100% newbie whereas today I am just a 98% newbie... Big > progress :-) ). Don't blame yourself -- the lack of a dedicated, singular naming convention for local objects has become quite a problem in UNIX (at least in terms of the mess it creates). In the end, w/ all kinds of possibilities being reserved, me ended up w/ the convention 'ls_' -- w/ the underscore at the end, since also in many non-zsh contexts, names w/ a preceding underscore are already reserved for ``underfloor'' system use. This is not elegant. (Me's also been using the 'ls0' numbers convention, but to me, that implies a lower-level version of the routine, not a higher-level one; and what about programs w/ names like 'doom2'? Should the wrapper be called 'doom20'? <g>). There's also the related problem of there being no record, upon exec(3) (or, rather, execve(2)), of where in the PATH array the executable was encountered, so that wrapper programs would have to pull all kinds of tricks to properly invoke the underlying program (to prevent the wrapper script from executing itself again instead); understandably, at that point, coders usually bail out and include the full path to the intended program. At least zsh *somewhat* mitigates this by having a 'command' modifier that actually forces it to use ${PATH}, but that only helps when, as in your case, the wrapper routine (or alias) is confined to the shell. Mein 2 Groschen. --zeurkous. -- Friggin' Machines! ^ permalink raw reply [flat|nested] 5+ messages in thread
* FU: RE: Re: ls completion 2024-06-04 13:19 ` zeurkous @ 2024-06-04 14:09 ` zeurkous 0 siblings, 0 replies; 5+ messages in thread From: zeurkous @ 2024-06-04 14:09 UTC (permalink / raw) To: Thomas Lauer, Bart Schaefer; +Cc: Zsh Users On Tue, 04 Jun 2024 13:19:35 +0000 (UTC), zeurkous@blaatscaahp.org wrote: > There's also the related problem of there being no record, upon exec(3) > (or, rather, execve(2)), of where in the PATH array the executable was > encountered, so that wrapper programs would have to pull all kinds of > tricks to properly invoke the underlying program (to prevent the > wrapper script from executing itself again instead); understandably, at > that point, coders usually bail out and include the full path to the > intended program. Menow realizes me's been slightly unclear here. Just so there's no confusion: this applies when the wrapper program is *not* named differently from the wrapped-around program. (Sometimes, perhaps often, an identical name is desirable or even required.) --zeurkous. -- Friggin' Machines! ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-06-04 14:12 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-06-03 16:56 ls completion Thomas Lauer 2024-06-03 20:40 ` Bart Schaefer 2024-06-04 12:34 ` Thomas Lauer 2024-06-04 13:19 ` zeurkous 2024-06-04 14:09 ` FU: " zeurkous
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).