Add apt-get subcommand detection alongside apt handling, including cached
lookup from apt-get help output and fallback built-in subcommands.
Update tests to verify valid apt-get subcommands are highlighted as commands
and invalid ones as unknown tokens.feat(main): highlight apt-get subcommands
Add apt-get subcommand detection alongside apt handling, including cached
lookup from apt-get help output and fallback built-in subcommands.
Update tests to verify valid apt-get subcommands are highlighted as commands
and invalid ones as unknown tokens.
Detect apt subcommands after runnable apt invocations and mark known
subcommands as commands while styling unknown ones as unknown tokens.
Load apt subcommands lazily from apt help with a built-in fallback list so
highlighting works across apt versions. Add tests for valid and invalid apt
subcommand handling.feat(main): highlight invalid apt subcommands distinctly
Detect apt subcommands after runnable apt invocations and mark known
subcommands as commands while styling unknown ones as unknown tokens.
Load apt subcommands lazily from apt help with a built-in fallback list so
highlighting works across apt versions. Add tests for valid and invalid apt
subcommand handling.
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
