Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] _virsh (Was: Re: zsh virsh completion)
- X-seq: zsh-workers 39159
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: [PATCH] _virsh (Was: Re: zsh virsh completion)
- Date: Fri, 02 Sep 2016 17:02:09 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1472828530; bh=R/YOi4oeDK/5jESFoJqZDXp2iI5jxU/8QqurjkayS1k=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=SiMlWwv4T/lZPeHDFJIhPKcwckZBdYAKe7NKKPeTIZ3gWNa8lP8fhFFht2D4bx0h9O1JR75YQdATUCbkv5b12dB7ARD2AHxcPYCAL1SwG3kltBYbaxvwT+knKKqavDlaet3T3pJI0FGA/4qwRR8RhRp6aE9UmkKBpChUEgDjPnF66TMU27xY6y6HJeMnR3UqDUoDkjTIfEYRgqimR757dJSf/a2wgDdapKjTOu88xWpdXoXUY0fPBFYsoCdFPPPve79NM1wWYuVS5nDYk10QfFvlhZgYplAgKLC8h1SHL3E2emD+1pQ+bykWTUCOB3T1zexQ479CMNK+fyQDNXkd1g==
- In-reply-to: <20160902052342.GA8514@fujitsu.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <8eb6dce0-50d7-5ab2-503a-194c1de2e45d@redhat.com> <20160713045957.GA3893@tarsus.local2> <9968da53-c1fd-fa2a-f30c-c74f884d2478@redhat.com> <20160720065832.GA28939@tarsus.local2> <699166a0-b0f0-452c-2561-b7e3cc952062@redhat.com> <25001.1469117569@hydra.kiddle.eu> <20160722071927.GG2521@tarsus.local2> <12554.1472678120@hydra.kiddle.eu> <20160902052342.GA8514@fujitsu.shahaf.local2>
Daniel Shahaf wrote:
> However, your patch seems to implement something slightly different: the
> patch executes sudo when (-p was passed, and) 'gain-privs' is either
> unset or set to true, whereas the above paragraphs seem to be arguing
> for *not* using sudo when the style is unset? Perhaps I misunderstood
> your argument.
The code is what I intended.
It also requires sudo to be present on the command-line being typed
so it seemed reasonable. And it is consistent with the remote-access
style. I don't have a strong opinion either, however. It was the
unconditionally hard-coded sudo that I did have a strong opinion
on.
> Executing a command as sudo upon pressing <TAB> could have undesired
> results in two ways: if the user _has_ sudo, executing the command with
> sudo could surprise her; and if user _doesn't_ have sudo, executing the
> command might result in an email from sudo to the root user.
If a user does:
sudo virsh start --domain <tab>
then yes, it might send off a mail to root but they'd get that anyway
when they actually try to run the command they're composing.
> I see: the privileges gained need not be privileges on the local system.
Or it might be something else like switch to the httpd user to run the
command.
> > It'd perhaps be useful if
> > the -p option to _call_program also caused it to add something to
> > $curcontext when looking up the command style but I'm not sure where
> > that could be done as we already have the tag and argument fields
> > filled. Any ideas?
>
> I suppose it fits best in the "command" part of the context, e.g.,
> could look up :completion::complete:f-under-sudo::lipsum or so.
Perhaps f/sudo? / can't appear in the command name.
> Come to think of it, sudoers(5) allows per-command defaults, so if the
> completion of the command 'foo' invokes «_call_program -b bar», the
> sudoers(5) Defaults!foo clauses wouldn't fire. Hopefully that will do
> nothing worse than failing to find completion.
At worst, the command will be blocked with a root e-mail. User will need
to set the command or gain-privileges style.
I also wonder if the prefix perhaps has other uses. With env for
instance.
> Could we please not introduce any more short opaque names? "priv" is
> ambiguous/unclear. Perhaps _comp_gain_privs_prefix. (Or perhaps the
> style name should be "gain-privileges".)
_comp_gain_privs_prefix starts getting a bit long. And is less
user-visible. I'm happy with gain-privileges on the style.
> > + '*::arguments:{ _comp_priv_prefix=( $words[1] -n ${(kv)opt_args[(I)(-u|--user)]} )
; _normal }'
> You removed the space that followed the last colon; wouldn't that cause
The { … } form is a specifically handled form by _arguments and it
won't insert any arguments. So I think this should be fine.
The patch below is just documentation.
I felt that _comp_priv_prefix itself ought to be documented but
there wasn't an obvious place to put it. I could try to squeeze it
in under gain-privileges but is there any thoughts on adding a
section on standard variables as follows? Zsh convention would
probably be to use "parameters" instead of "variables" and I'll do
that if anyone objects but we might be doing our user's a favour
by ditching that particular convention.
I also inserted the otherwise undocumented _comp_caller_options
into that new section. Any thoughts on what else might go there?
curcontext, _compskip and service are covered elsewhere but it might
be clearer to reorganise them into this section.
I also moved the comppostfuncs documentation to this section. Does
that seem reasonable?
> Should $_comp_priv_prefix be left unset when (( ${+funcstack[(r)_ssh]} ))?
Yes. Very good point. And as a note to myself, I shouldn't have
sudo put any command substitutions into _comp_priv_prefix.
Oliver
diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
index 9e49913..dab73ef 100644
--- a/Doc/Zsh/compsys.yo
+++ b/Doc/Zsh/compsys.yo
@@ -1815,6 +1815,14 @@ In the case of the tt(_match) completer, the style may also be set to
the string `tt(pattern)'. Then the pattern on the line is left
unchanged if it does not match unambiguously.
)
+kindex(gain-privileges, completion style)
+item(tt(gain-privileges))(
+If set to tt(false), certain commands will be prevented from making
+use of commands like tt(sudo) or tt(doas) to gain extra privileges when
+retrieving information for completion. By default, this would only be
+done when a command such as tt(sudo) appears on the command-line. To
+force the use of, e.g. tt(sudo), the tt(command) style can be used.
+)
kindex(keep-prefix, completion style)
item(tt(keep-prefix))(
This style is used by the tt(_expand) completer. If it is `true', the
@@ -3400,12 +3408,6 @@ generating matches all follow the convention of returning status zero if they
generated completions and non-zero if no matching completions could be
added.
-Two more features are offered by the tt(_main_complete) function. The
-arrays tt(compprefuncs) and tt(comppostfuncs) may contain
-names of functions that are to be called immediately before or after
-completion has been tried. A function will only be called once unless
-it explicitly reinserts itself into the array.
-
startitem()
findex(_all_labels)
item(tt(_all_labels) [ tt(-x) ] [ tt(-12VJ) ] var(tag) var(name) var(descr) [ var(command) var(args) ... ])(
@@ -4012,7 +4014,7 @@ The return status of tt(_call_function) itself is zero if the function
var(name) exists and was called and non-zero otherwise.
)
findex(_call_program)
-item(tt(_call_program) var(tag) var(string) ...)(
+item(tt(_call_program) [ tt(-p) ] var(tag) var(string) ...)(
This function provides a mechanism for the user to override the use of an
external command. It looks up the tt(command) style with the supplied
var(tag). If the style is set, its value is used as the command to
@@ -4020,6 +4022,13 @@ execute. The var(string)s from the call to tt(_call_program), or from the
style if set, are concatenated with spaces between them and the resulting
string is evaluated. The return status is the return status of the command
called.
+
+If the option `tt(-p)' is supplied it indicates that the command output
+is influenced by the permissions it is run with. Unless disabled with
+the tt(gain-privileges) style or overidden with the tt(command) style,
+tt(_call_program) will make use of commands such as tt(sudo) if
+present on the command-line, to match the permissions to whatever the
+final command is likely to run under.
)
findex(_combination)
item(tt(_combination) [ tt(-s) var(pattern) ] var(tag) var(style) var(spec) ... var(field) var(opts) ...)(
@@ -4875,7 +4884,38 @@ the same meaning as for tt(_description).
)
enditem()
-texinode(Completion Directories)()(Completion Functions)(Completion System)
+texinode(Completion System Variables)(Completion Directories)(Completion Functions)(Completion System)
+sect(Completion System Variables)
+cindex(completion system, variables)
+
+There are some standard variables, initialised by the tt(_main_complete)
+function and then used from other functions.
+
+The standard variables are:
+
+startitem()
+item(tt(_comp_caller_options))(
+The completion system uses tt(setopt) to set a number of options. This
+allows functions to be written without concern for compatibility with
+every possible combination of user options. However, sometimes completion
+needs to know what the user's option preferences are. These are saved
+in the tt(_comp_caller_options) associative array.
+)
+
+item(tt(_comp_priv_prefix))(
+Completion functions such as tt(_sudo) can set the tt(_comp_priv_prefix)
+array to a command that may then be used by tt(_call_program) to
+match the permissions when calling programs to generate matches.
+)
+enditem()
+
+Two more features are offered by the tt(_main_complete) function. The
+arrays tt(compprefuncs) and tt(comppostfuncs) may contain
+names of functions that are to be called immediately before or after
+completion has been tried. A function will only be called once unless
+it explicitly reinserts itself into the array.
+
+texinode(Completion Directories)()(Completion System Variables)(Completion System)
sect(Completion Directories)
cindex(completion system, directory structure)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author