From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: [FEATURE][PATCH] Complete local executables with ./ prefix, if prefix-needed is false
Date: Wed, 08 Dec 2021 19:13:16 +0000 [thread overview]
Message-ID: <9df0a670-078b-449d-9439-127853f188a3@www.fastmail.com> (raw)
In-Reply-To: <CAH+w=7YY06OimsL6ZOi3Fm87CTHs_UDcSF6gHfA+J-VsdXyHeg@mail.gmail.com>
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@daniel.shahaf.name> 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
next prev parent reply other threads:[~2021-12-08 19:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 19:15 Marlon Richert
2021-12-08 0:22 ` Aaron Schrab
2021-12-08 0:50 ` Bart Schaefer
2021-12-08 1:16 ` Aaron Schrab
2021-12-08 16:25 ` Daniel Shahaf
2021-12-08 17:07 ` Bart Schaefer
2021-12-08 19:13 ` Daniel Shahaf [this message]
2021-12-08 23:16 ` Oliver Kiddle
2021-12-08 23:42 ` Bart Schaefer
2021-12-09 21:19 ` Oliver Kiddle
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=9df0a670-078b-449d-9439-127853f188a3@www.fastmail.com \
--to=d.s@daniel.shahaf.name \
--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).