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.
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.
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
See comments within for the rationale.
This is a regression test for a regression that was only present in development
versions of PR #764 and was never present in master.
Fixes#202.
Test expectations are updated. For example, BUFFER='/bin' is now
highlighted as path_prefix because it's a prefix of '/bin/sh' which
would be valid. However, BUFFER='/bin;' is now properly highlighted
as an error (unless AUTO_CD is set).
This is not perfect: we don't try to detect cases such as «$((ls); (ls))»,
which look like arithmetic expansions but are in fact command substitutions.
Fixes part of #607.
Introduces #704.
Manish Tiwari
Daniel Shahaf
Matthew Martin
m0viefreak
Nikola Knezevic
Roman Perepelitsa
Daniel Shahaf