In _zsh_highlight_main__type :
- the calls to "builtin type -w -- $1" are replaced by call to "sh_highlight_main__test_type_builtin"
- if ZSH_HIGHLIGHT_SPECIAL_PATH exists but is empty, "foo" in "sudo foo" is always red
- if ZSH_HIGHLIGHT_SPECIAL_PATH is not empty, zsh searchs in the PATH "ZSH_HIGHLIGHT_SPECIAL_PATH" to know if the command "foo" in "sudo foo" exists
- if "foo" is in ZSH_HIGHLIGHT_SPECIAL_COMMAND then "Admin" says that user has access to this command : foo in "sudo foo" is green
The effect of the bug was that «-:» was considered an option taking an argument
(see the parsing of the associative array in lines 692-693).
As to preventing recurrence, add a warning comment. We _could_ change
the separator from colon to something else, but colon is idiomatic for
this use (see, e.g., passwd(5)), and the problem will be unlikely to
recur if and when we add a third field to the assoc's values. (For
example, jexec(1), chroot(1), and even ssh(1) would benefit from a third
field saying how many positional arguments to skip before the positional
argument that's to be the command word — though in the last two cases,
specifying an "inner" command is optional.)
As of this writing, it seems that the 'type' builtin poisons the commands hash
in a way that breaks AUTO_CD to absolute paths that don't end with a slash.
* i511-bang-pipeline:
main: Fold '!' handling in to the 'case'. No functional change.
Fix indentation. No functional change.
main: Fix highlighting of the ! precommand after array assignments. Add tests.
main: Highlight the ! precommand as an error when not at the start of a pipeline.
Update the test point for f3410c5862fc6d89ee3661f7d140e570d6740e8c (#264),
which changed the highlighting of aliases to consider what they resolve to.
Now the test file has both ${aliases[alias1]} and ${functions[alias1]},
the expectation is 'alias', and passes; thus:
Fixes#588.
The test never actually defined a function named 'alias1', not even
when zsh 5.4 warned it about this (see 9523d6d49cb3d4db5bd84c3cec6168a2057fe3ab,
which was wrong and is hereby reverted).
The test that's now failing has been filed as issue #558.
