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