Per Copilot review on #987: _zsh_highlight_main__type's cache is keyed
on the command name alone, so classifying a name once under PATH_DIRS
(e.g. as a plain top-level command) would silently poison later
lookups of that same name after sudo -- and vice versa -- regardless
of the PATH_DIRS removal, since the cache lookup happens before
$options_to_set is even consulted.
Give _zsh_highlight_main__type an explicit no_cache parameter, and
add _zsh_highlight_main__type_maybe_no_pathdirs(), a small wrapper
that only shadows $options_to_set (and only bypasses the cache) when
PATH_DIRS was actually present to remove -- so a user without
PATH_DIRS set sees this codepath do nothing at all. Both call sites
in the main word-classification block now go through this wrapper
instead of duplicating the shadowing logic inline.
Strengthened sudo-path_dirs.zsh to classify the same name twice in
one buffer (plain, then sudo-prefixed) specifically to exercise this
cache interaction, not just the PATH_DIRS removal in isolation.
Verified via WSL zsh 5.9: make test passes (same 28 pre-existing
TODO failures, zero new), and the strengthened test fails as expected
(observes "command" instead of "unknown-token" on the sudo-prefixed
occurrence) when run against the pre-fix highlighter.
sudo(8) (and env, nice, and other entries in \$precommand_options)
resolve their target command via execvp(3)-style lookup, which never
searches \$path for a name containing a slash -- unlike the shell's
own PATH_DIRS option. So "sudo foo/bar" was highlighted as a valid
command whenever the user had PATH_DIRS set and some \$path element
made "foo/bar" resolvable that way, even though sudo itself would
fail to find it.
:sudo_opt: already marks every word from a recognised precommand up
to and including its actual command word (for any precommand in
\$precommand_options, not just sudo). Key off that existing marker to
shadow PATH_DIRS out of \$options_to_set for just those two
_zsh_highlight_main__type calls, via an anonymous-function scope so
the shadow reverts automatically and normal command-word classification
elsewhere in the line is unaffected.
Fixes#595.
test-highlighting.zsh and test-perfs.zsh were linked as tests/test-*.zsh,
but this file already lives in tests/, so the links resolved to
tests/tests/test-*.zsh and 404'd. Found by pointing a markdown
link-checker at the repo.
It's actually unavailable in the minimal chroots Debian builds our
package on. That's allowed by POSIX, which specifies ps(1) to be
optional, whereas id(1) —
- is not optional in POSIX
- should exist on every system anyone might run the testsuite on
- has the same length name, so test expectations don't have to be updated
- doesn't take a filename argument (ditto)
That does make the pipeline as a whole somewhat nonsensical
semantically, but it remains just as valid syntactically.
Args for proxychains should be f:q => -f file : -q quiet.
From comments in the same function:
# $precommand_options maps precommand name to values of $flags_with_argument,
# $flags_sans_argument, and flags_solo for that precommand, joined by a
# colon.
5.8.0.3 was correct until 5.8.1 was released (see the great-grandparent of this
commit, "driver: Bump the in-development is-at-least checks so they return
false on zsh 5.8.1, released yesterday").
5.2 -> 5.3 is simply a typo fix. zle-line-pre-redraw has been available since then.
PR #776 fixed an issue with complex aliases and expansion. However, this change
also introduced a problem with aliases which contain `]` (for example, commonly
seen on macOS: `alias ]=open`), due to using an associative array `seen_alias`,
indexed by the alias name. Due to `"$seen_alias[$arg]"`, it would fail when
`$arg` is expanded to anything containing `]`'. Thus, typing `] /` would result
in:
```
> ] /
(anon):unset:3: seen_alias[]]: invalid parameter name
```
This change fixes the issue by ensuring we properly access keys in the
associative array `seen_alias`.
Older versions of zsh have issues with map keys having special
characters, especially lacking ways to remove such keys. The
issue is described in detail in
https://unix.stackexchange.com/questions/626393/in-zsh-how-do-i-unset-an-arbitrary-associative-array-element.
This fix uses proposal from
[zsh-workers/43269](https://www.zsh.org/mla/workers/2018/msg01073.html),
discovered by Stephane Chazelas, that boils down to avoid removing keys
from the map, and reconstruct the map anew with some keys omitted.
Co-authored-by: @phy1729
Manish Tiwari
Manish Tiwari
Colin Kinloch
Matthew Martin
Daniel Shahaf
m0viefreak
Mario P. Cardenas
Henry Bley-Vroman
Johan van Eck
DiegoBoy
inventor500
Nuri Jung
Daniel Kuettel
Leonardo Gama
a1346054
Robert
Nikola Knezevic