Re: [FEATURE][PATCH] Complete local executables with ./ prefix, if prefix-needed is false

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Wed, 08 Dec 2021 17:07 +00:00:
> On Wed, Dec 8, 2021 at 8:31 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>> ...[Perhaps] a better approach here would be to complete
>> both executables in $PATH and executables in $PWD, but under separate
>> tags.  If we did that, prefix-needed would have its usual semantics in
>> this case.
>>
>> Second, if Alice's $PATH does not include "." and her zstyle settings
>> are such that «zstyle -T :…:executables prefix-needed» is false, why
>> should the implied prefix be "./"?
>
> […] Does your question imply that it should instead be possible to
> complete executables from arbitrary location(s) outside $path, rather
> than only locally?

I was not trying to imply that we should complete executables from
arbitrary locations, but to ask whether we should do that.

What use-cases are there for wanting a prefix other than "./" to be
implied? (not as the default behaviour, but as an opt-innable behaviour)

Brainstorming:

    ./bin/
    # Could be useful at the root of a project tree whose local scripts
    # (such as our Util/preconfig) are under an FHS-esque ./bin/
    # directory.

    .//
    # to complete in subdirectories of $PWD.  E.g., «mk<TAB>» would
    # offer «Util/mkdisttree.sh» in zsh.git and «src/mkhelp.pl» in
    # curl.git, as «.//mk<TAB>» does.
    #
    # Today, to complete either of those, one would type «s/mk<TAB>» or
    # «U/mk<TAB>».  Supporting this would save typing "s/" or "U/", just
    # like the OP saves typing "./".

    ../
    # to complete in $PWD's parent.  E.g., when one has version control
    # worktrees of several branches of a single repository in sibling
    # directories (e.g., ~/src/zsh/{master,5.8,5.7}/), the common parent
    # directory is an obvious place for scripts that might need to run
    # in any branch's worktree.

    "$(git rev-parse --show-toplevel)/../"
    # Ditto, but from anywhere in the worktree.

    /absolute/path/to/the/src/tree/
    # when $PWD is the build tree of an out-of-tree build.  Useful for
    # running «configure» a second time, or for running just one piece
    # of a test suite (calling the scripts directly rather than via
    # «make test»).

    /sbin/
    # This would allow completing «ifcon<TAB>» to «/sbin/ifconfig»
    # without affecting child processes, and would cause such command
    # names to always appear in history as absolute paths.  Alternatives
    # including adding /sbin to $PATH or «command-path».

I also considered a prefix of «=» and semantics involving the EQUALS
option, but haven't come up with anything.

> If so, then instead of (or as well as?) prefix-needed, an array-valued
> style 'executable-prefixes' (or whatever) could provide a list of
> places that should be searched and automatically inserted ahead of the
> command word.  If combined with the patch's prefix-needed semantic,
> one would need to both set prefix-needed to false and set
> executable-prefixes to include "./" in order to get Marlon's effect.
> That would solve the "silently get new behavior" issue

*nod*

> and (I think) also allow one to e.g. add "/etc/" when completing
> commands after "sudo"?

I guess that would involve inspecting ${+funcstack[(r)_sudo]} or
${_comp_priv_prefix}.

> One might then also be able to use the existing mechanisms to create
> additional tag names, rather than wiring a new tag name into
> _command_names.  (This is vaguely similar to Zach's question about
> adding a custom tag to "cd" completion.)

Thanks, Bart.

Daniel