'main': Follow-up to last commit: Fix stdbuf options spec.

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.)
This commit is contained in:
Daniel Shahaf 2019-03-27 11:45:17 +00:00
parent 3e86ef59b7
commit 5f80147c55

View File

@ -295,7 +295,8 @@ _zsh_highlight_highlighter_main_paint()
# that wouldn't be followed by a colon in a getopts specification.
local flags_sans_argument
# $precommand_options maps precommand name to values of $flags_with_argument and
# $flags_sans_argument for that precommand, joined by a colon.
# $flags_sans_argument for that precommand, joined by a colon. (The value is NOT
# a getopt(3) spec, although it resembles one.)
#
# Currently, setting $flags_sans_argument is only important for commands that
# have a non-empty $flags_with_argument; see test-data/precommand4.zsh.
@ -313,7 +314,7 @@ _zsh_highlight_highlighter_main_paint()
'nice' n: # as of current POSIX spec
'pkexec' '' # doesn't take short options; immune to #121 because it's usually not passed --option flags
'sudo' Cgprtu:AEHKPSVbhiklnsv # as of sudo 1.8.21p2
'stdbuf' i:o:e:
'stdbuf' ioe:
)
if [[ $zsyh_user_options[ignorebraces] == on || ${zsyh_user_options[ignoreclosebraces]:-off} == on ]]; then