ls completion

ls completion

[Thomas Lauer]

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

Re: ls completion

[Bart Schaefer]

[-- 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 --]

Re: ls completion

[Thomas Lauer]

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

RE: Re: ls completion

[zeurkous]

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!

FU: RE: Re: ls completion

[zeurkous]

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!