zsh-workers
 help / color / mirror / Atom feed
* Re: sudo autocompletion
       [not found]       ` <ADE72275-1311-44BE-9B1D-5E617E3D9F94@gmail.com>
@ 2020-02-10 17:13         ` dana
  2020-02-10 17:40           ` Peter Stephenson
                             ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: dana @ 2020-02-10 17:13 UTC (permalink / raw)
  To: Andrey; +Cc: Daniel Shahaf, Zsh hackers list

On 10 Feb 2020, at 01:52, Andrey <butirsky@gmail.com> wrote:
> Thanks, will try it. How about to include it in distribution by default?

Would this be too cheeky?

There's not much precedent for this sort of thing (just cache-policy), but i
don't think it'd cause any issues, aside from showing too many commands in
some uncommon cases...?

(Moved to -workers)

dana


diff --git a/Completion/Unix/Command/_sudo b/Completion/Unix/Command/_sudo
index 41e32cbae..52b212176 100644
--- a/Completion/Unix/Command/_sudo
+++ b/Completion/Unix/Command/_sudo
@@ -54,6 +54,18 @@ else
     '(-)1:command: _command_names -e'
     '*::arguments:{ _comp_priv_prefix=( $cmd -n ${(kv)opt_args[(I)(-[ugHEP]|--(user|group|set-home|preserve-env|preserve-groups))]} ) ; _normal }'
   )
+
+  # By default, _command_names uses the current PATH to complete commands. This
+  # doesn't necessarily make sense for sudo on systems that use its secure_path
+  # feature -- a common issue is that /**/sbin appear in secure_path but not in
+  # unprivileged users' PATHs. Ideally we could parse the correct value out of
+  # `sudo -l`, but since that requires a password it won't work half the time.
+  # To do the right thing in the most common cases, we'll simply ensure that the
+  # sbin variants always appear in the default command-path (bash-completion's
+  # _sudo does something similar)
+  zstyle -t ":completion:${curcontext}:" command-path ||
+  zstyle -e ":completion:${curcontext%:}:*" command-path \
+    'reply=( $path ${path/%\/bin//sbin} )'
 fi
 
 _arguments -s -S $args


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-10 17:13         ` sudo autocompletion dana
@ 2020-02-10 17:40           ` Peter Stephenson
  2020-02-10 18:57             ` dana
  2020-02-10 19:20           ` Daniel Shahaf
  2020-02-10 22:05           ` Andrey Butirsky
  2 siblings, 1 reply; 15+ messages in thread
From: Peter Stephenson @ 2020-02-10 17:40 UTC (permalink / raw)
  To: zsh-workers

On Mon, 2020-02-10 at 11:13 -0600, dana wrote:
> On 10 Feb 2020, at 01:52, Andrey <butirsky@gmail.com> wrote:
> > 
> > Thanks, will try it. How about to include it in distribution by default?
> Would this be too cheeky?
> 
> There's not much precedent for this sort of thing (just cache-policy), but i
> don't think it'd cause any issues, aside from showing too many commands in
> some uncommon cases...?
>
> +  zstyle -t ":completion:${curcontext}:" command-path ||
> +  zstyle -e ":completion:${curcontext%:}:*" command-path \
> +    'reply=( $path ${path/%\/bin//sbin} )'

I think it ought at least to check if the /sbin directories exist.
Possibly they should also go in front of the path --- that's one of the
points about "secure".

On the issue of setting the style at this point --- the usual behaviour
is only to change the default locally rather than also set the style, but
that's probably difficult here, so I don't think it's a particularly big
deal.

pws


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-10 17:40           ` Peter Stephenson
@ 2020-02-10 18:57             ` dana
  0 siblings, 0 replies; 15+ messages in thread
From: dana @ 2020-02-10 18:57 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh hackers list

On 10 Feb 2020, at 11:40, Peter Stephenson <p.stephenson@samsung.com> wrote:
> I think it ought at least to check if the /sbin directories exist.

Won't they just be ignored if they don't? It might be a little nicer to return
like ${(u)^reply}(/N), though

On 10 Feb 2020, at 11:40, Peter Stephenson <p.stephenson@samsung.com> wrote:
> Possibly they should also go in front of the path --- that's one of the
> points about "secure".

Not sure about that. We only want to use this for completion, not actually
resolving commands, especially if we're doing it this way where we just
blindly replace */bin by */sbin (as opposed to white-listing a few known
directories like bash does). I don't think any external commands are called
after this anyway, but...

On 10 Feb 2020, at 11:40, Peter Stephenson <p.stephenson@samsung.com> wrote:
> On the issue of setting the style at this point --- the usual behaviour
> is only to change the default locally rather than also set the style, but
> that's probably difficult here, so I don't think it's a particularly big
> deal.

I was initially going to have it update path locally, and again it'd probably
be fine here, but i figured it'd be preferable to keep that logic in
_command_names

dana


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-10 17:13         ` sudo autocompletion dana
  2020-02-10 17:40           ` Peter Stephenson
@ 2020-02-10 19:20           ` Daniel Shahaf
  2020-02-11 10:12             ` Oliver Kiddle
  2020-02-10 22:05           ` Andrey Butirsky
  2 siblings, 1 reply; 15+ messages in thread
From: Daniel Shahaf @ 2020-02-10 19:20 UTC (permalink / raw)
  To: zsh-workers

dana wrote on Mon, 10 Feb 2020 11:13 -0600:
> +++ b/Completion/Unix/Command/_sudo
> @@ -54,6 +54,18 @@ else
> +  # By default, _command_names uses the current PATH to complete commands. This
> +  # doesn't necessarily make sense for sudo on systems that use its secure_path
> +  # feature -- a common issue is that /**/sbin appear in secure_path but not in
> +  # unprivileged users' PATHs. Ideally we could parse the correct value out of
> +  # `sudo -l`, but since that requires a password it won't work half the time.
> +  # To do the right thing in the most common cases, we'll simply ensure that the
> +  # sbin variants always appear in the default command-path (bash-completion's
> +  # _sudo does something similar)
> +  zstyle -t ":completion:${curcontext}:" command-path ||

Might the user have set the command-path style in this context to
an empty value (zero strings, which would count as false)?

> +  zstyle -e ":completion:${curcontext%:}:*" command-path \
> +    'reply=( $path ${path/%\/bin//sbin} )'

Could this style setting shadow a style the user had set explicitly?
(e.g., because the pattern here is more specific than the pattern the
user has set)

As an alternative, _sudo could set _comp_command_path=( $path
$path/%\/bin//sbin ) and then _command_names could use that value if
the style isn't set then.  The parameter would be made local by
_main_complete.  This is similar to how, say, $precommands is handled.

HTH,

Daniel
[who was going to add this to zsh-sensible, but prefers fixing this
in zsh.git if possible :)]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-10 17:13         ` sudo autocompletion dana
  2020-02-10 17:40           ` Peter Stephenson
  2020-02-10 19:20           ` Daniel Shahaf
@ 2020-02-10 22:05           ` Andrey Butirsky
  2020-02-10 23:02             ` dana
  2 siblings, 1 reply; 15+ messages in thread
From: Andrey Butirsky @ 2020-02-10 22:05 UTC (permalink / raw)
  To: dana; +Cc: Daniel Shahaf, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

On 10.02.2020 20:13, dana wrote:
> diff --git a/Completion/Unix/Command/_sudo 
> b/Completion/Unix/Command/_sudo
> index 41e32cbae..52b212176 100644
> --- a/Completion/Unix/Command/_sudo
> +++ b/Completion/Unix/Command/_sudo
> @@ -54,6 +54,18 @@ else
>       '(-)1:command: _command_names -e'
>       '*::arguments:{ _comp_priv_prefix=( $cmd -n ${(kv)opt_args[(I)(-[ugHEP]|--(user|group|set-home|preserve-env|preserve-groups))]} ) ; _normal }'
>     )
> +
> +  # By default, _command_names uses the current PATH to complete commands. This
> +  # doesn't necessarily make sense for sudo on systems that use its secure_path
> +  # feature -- a common issue is that /**/sbin appear in secure_path but not in
> +  # unprivileged users' PATHs. Ideally we could parse the correct value out of
> +  # `sudo -l`, but since that requires a password it won't work half the time.
> +  # To do the right thing in the most common cases, we'll simply ensure that the
> +  # sbin variants always appear in the default command-path (bash-completion's
> +  # _sudo does something similar)
> +  zstyle -t ":completion:${curcontext}:" command-path ||
> +  zstyle -e ":completion:${curcontext%:}:*" command-path \
> +    'reply=( $path ${path/%\/bin//sbin} )'
>   fi
>   
>   _arguments -s -S $args
>
Didn't see all the file, but probably 'su' and variants need something 
similar also?

One of the "solutions" 
(https://forums.gentoo.org/viewtopic-p-7978544.html?sid=fd1853347362adf53e40a5a0320030a8#7978544):

|[[ $UID -eq 0 ]] || () {||
||        local i||
||        local -T SUDO_PATH sudo_path||
||        local -U sudo_path=($path {,/usr{,/local}}/sbin(N-/))||
||
||        for i in su{,do}; do||
||                zstyle ":completion:*:$i:*" environ PATH="$SUDO_PATH"||
||        done||
||}|



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-10 22:05           ` Andrey Butirsky
@ 2020-02-10 23:02             ` dana
  0 siblings, 0 replies; 15+ messages in thread
From: dana @ 2020-02-10 23:02 UTC (permalink / raw)
  To: Andrey Butirsky; +Cc: Daniel Shahaf, Zsh hackers list

On 10 Feb 2020, at 16:05, Andrey Butirsky <butirsky@gmail.com> wrote:
> Didn't see all the file, but probably 'su' and variants need something similar also?
> One of the "solutions"...:
> zstyle ":completion:*:$i:*" environ PATH="$SUDO_PATH"

FYI, _su doesn't currently support the environ style, so that isn't actually
doing anything for it.

I don't think using environ is a good idea for us. It'd update PATH just like
command-path ultimately does, but it happens sooner, it exports the change,
and because it supports multiple var=value pairs we'd have to do some weird
accounting to provide a default without ruining completion if someone uses it
to set HOME or whatever.

I think you're right that we probably need to do something for su and doas
too, though. I very rarely use them so i'd have to double-check how they
actually handle PATH

On 10 Feb 2020, at 13:20, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Might the user have set the command-path style in this context to
> an empty value (zero strings, which would count as false)? ...
> Could this style setting shadow a style the user had set explicitly?

Yes and yes. The first is easily fixed, but the second is weird due to how
zstyle weights patterns. That's an issue with cache-policy as well

On 10 Feb 2020, at 13:20, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> As an alternative, _sudo could set _comp_command_path=( $path
> $path/%\/bin//sbin ) and then _command_names could use that value if
> the style isn't set then.  The parameter would be made local by
> _main_complete.  This is similar to how, say, $precommands is handled.

That seems like it'd work. We could also give _command_names an option to do
it for us, similar to what we did recently with _normal. Both are API changes,
though, so we'd be stuck with it. Have to think about it

dana


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-10 19:20           ` Daniel Shahaf
@ 2020-02-11 10:12             ` Oliver Kiddle
  2020-02-11 10:28               ` Setting/Querying cache-policy (was: Re: sudo autocompletion) Daniel Shahaf
  2020-02-13  1:21               ` sudo autocompletion dana
  0 siblings, 2 replies; 15+ messages in thread
From: Oliver Kiddle @ 2020-02-11 10:12 UTC (permalink / raw)
  To: zsh-workers; +Cc: Daniel Shahaf, dana

Daniel Shahaf wrote:
> dana wrote on Mon, 10 Feb 2020 11:13 -0600:
> > +  zstyle -e ":completion:${curcontext%:}:*" command-path \
> > +    'reply=( $path ${path/%\/bin//sbin} )'

I don't like it when completion functions set zstyles. I know that the
cache functions do it but even with one bad precedent I think it is
better to not proliferate the practice further. Without testing this,
I'm sceptical that the context will match at the right times - it'll
contain sudo as the command component but that may not persist.

For a solution in _sudo, the environ style is perhaps better because
that is directly where it is looked up.

> As an alternative, _sudo could set _comp_command_path=( $path
> $path/%\/bin//sbin ) and then _command_names could use that value if

We already set _comp_priv_prefix, _command_names could detect that
and adjust a local $path if it is set. That has the added advantage
of keeping the definition of the root PATH in one place rather than
repeated for doas, sudo etc. This is the sort of thing _comp_priv_prefix
was created for.

Oliver

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Setting/Querying cache-policy (was: Re: sudo autocompletion)
  2020-02-11 10:12             ` Oliver Kiddle
@ 2020-02-11 10:28               ` Daniel Shahaf
  2020-02-12 16:51                 ` dana
  2020-02-13  1:21               ` sudo autocompletion dana
  1 sibling, 1 reply; 15+ messages in thread
From: Daniel Shahaf @ 2020-02-11 10:28 UTC (permalink / raw)
  To: zsh-workers

Oliver Kiddle wrote on Tue, 11 Feb 2020 11:12 +0100:
> Daniel Shahaf wrote:
> > dana wrote on Mon, 10 Feb 2020 11:13 -0600:  
> > > +  zstyle -e ":completion:${curcontext%:}:*" command-path \
> > > +    'reply=( $path ${path/%\/bin//sbin} )'  
> 
> I don't like it when completion functions set zstyles. I know that the
> cache functions do it but even with one bad precedent I think it is
> better to not proliferate the practice further.

+1

Speaking of the cache-policy style, why do the following places use
":completion:*:*:$service:*" in the «zstyle -s» call?  Shouldn't that
use ${curcontext}?

% ag cache-policy Completion/ | grep -v curcontext | vipe
Completion/Debian/Type/_deb_packages:101:  zstyle -s ":completion:*:*:$service:*" cache-policy update_policy
Completion/Debian/Type/_deb_packages:103:    zstyle ":completion:*:*:$service:*" cache-policy _debs_caching_policy
Completion/Debian/Command/_apt:629:  zstyle -s ":completion:*:*:$service:*" cache-policy update_policy
Completion/Debian/Command/_apt:631:    zstyle ":completion:*:*:$service:*" cache-policy _apt_caching_policy
Completion/Darwin/Type/_retrieve_mac_apps:64:  zstyle -s ":completion:*:*:$service:*" cache-policy cache_policy
Completion/Darwin/Type/_retrieve_mac_apps:66:    zstyle ":completion:*:*:$service:*" cache-policy _mac_apps_caching_policy
Completion/Redhat/Command/_rpm:433:zstyle -s ":completion:*:*:rpm:*" cache-policy update_policy
Completion/Redhat/Command/_rpm:435:  zstyle ":completion:*:*:rpm:*" cache-policy _rpms_caching_policy
Completion/Unix/Command/_subversion:26:  zstyle -s ":completion:*:*:$service:*" cache-policy update_policy
Completion/Unix/Command/_subversion:28:    zstyle ":completion:*:*:$service:*" cache-policy _svn_caching_policy
Completion/Unix/Command/_gradle:13:zstyle -s ":completion:*:*:$service:*" cache-policy cache_policy || \
Completion/Unix/Command/_gradle:14:    zstyle ":completion:*:*:$service:*" cache-policy _gradle_caching_policy
Completion/Unix/Command/_composer:802:    zstyle -s ":completion:*:*:$service:*" cache-policy tmp
Completion/Unix/Command/_composer:804:    zstyle ":completion:*:*:$service:*" cache-policy __composer_cache_policy
Completion/Linux/Command/_modutils:18:  zstyle -s ":completion:*:*:$service:*" cache-policy update_policy
Completion/Linux/Command/_modutils:20:    zstyle ":completion:*:*:$service:*" cache-policy _modules_caching_policy
Completion/Linux/Command/_opkg:301:  zstyle -s ":completion:*:*:$service:*" cache-policy cache_policy
Completion/Linux/Command/_opkg:303:  zstyle ":completion:*:*:$service:*" cache-policy __opkg_cache_policy

Cheers,

Daniel	

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Setting/Querying cache-policy (was: Re: sudo autocompletion)
  2020-02-11 10:28               ` Setting/Querying cache-policy (was: Re: sudo autocompletion) Daniel Shahaf
@ 2020-02-12 16:51                 ` dana
  0 siblings, 0 replies; 15+ messages in thread
From: dana @ 2020-02-12 16:51 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On 11 Feb 2020, at 04:28, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Speaking of the cache-policy style, why do the following places use
> ":completion:*:*:$service:*" in the «zstyle -s» call?  Shouldn't that
> use ${curcontext}?

The former method seems right-ish for *setting* the styles (as right as you
can really be, at least?), but not for retrieving them. Probably just someone
copying and pasting without thinking about the implications? I'm sure that was
the case for the ones on there that i wrote, anyway

Will fix later

dana


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-11 10:12             ` Oliver Kiddle
  2020-02-11 10:28               ` Setting/Querying cache-policy (was: Re: sudo autocompletion) Daniel Shahaf
@ 2020-02-13  1:21               ` dana
  2020-02-13  1:29                 ` Bart Schaefer
  2020-02-15 22:22                 ` Andrey Butirsky
  1 sibling, 2 replies; 15+ messages in thread
From: dana @ 2020-02-13  1:21 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list, Daniel Shahaf

On 11 Feb 2020, at 04:12, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> We already set _comp_priv_prefix, _command_names could detect that
> and adjust a local $path if it is set.

I made some related changes here that i can break out into separate patches if
it makes it easier. But this is the summary:

* Have _command_names append the sbin variants if command-path is not set but
  _comp_priv_prefix is

* Add some indirection around setting _c_p_p in _doas, _pfexec, and _sudo — i
  think the purpose of delaying the assignment is to make sure that opt_args
  has been populated

* Have _doas call `_command_names -e` separately like _sudo and _pfexec do (it
  can't complete shell commands)

* Have _pfexec use $words[1] for _c_p_p (the $cmd indirection is there because
  $words is changed by the *:: spec)

* Fix broken opt_args references in _doas and _pfexec — they need the (I)
  flag, and using argument sets in _doas makes it ugly to extract options, so
  i have it just using exclusion lists now instead

* Change -P to -P+ in _pfexec

Does this make sense?

PS: This does not fix `su -c` — _su doesn't set _c_p_p, presumably because it
always prompts for a password. But since _c_p_p is passed directly to eval, we
*could* make it set _c_p_p=( '' ), which would trick _command_names into doing
the right thing. Is that too silly?

dana


diff --git a/Completion/Solaris/Command/_pfexec b/Completion/Solaris/Command/_pfexec
index 2519c3cdc..fc2bca835 100644
--- a/Completion/Solaris/Command/_pfexec
+++ b/Completion/Solaris/Command/_pfexec
@@ -22,11 +22,15 @@ _privset() {
 }
 
 _pfexec() {
+	local cmd cpp
 	local -a _comp_priv_prefix
+	local -A opt_args
+	cmd="$words[1]"
+	cpp='_comp_priv_prefix=( $cmd ${(kv)opt_args[(I)-P]} )'
  	_arguments \
-		'-P[privileges to acquire]:privspec:_privset' \
- 		'(-):command name: _command_names -e' \
-		'*::arguments:{ _comp_priv_prefix=( pfexec ${(kv)opt_args[-P]} ) ; _normal }'
+		'-P+[privileges to acquire]:privspec:_privset' \
+ 		"(-): :{ $cpp; _command_names -e }" \
+		"*:: :{ $cpp; _normal }"
 }
 
 _pfexec "$@"
diff --git a/Completion/Unix/Command/_doas b/Completion/Unix/Command/_doas
index 94395557c..2494f1c5f 100644
--- a/Completion/Unix/Command/_doas
+++ b/Completion/Unix/Command/_doas
@@ -1,7 +1,8 @@
 #compdef doas
 
-local environ e cmd
+local environ e cmd cpp
 local -a _comp_priv_prefix
+local -A opt_args
 
 zstyle -a ":completion:${curcontext}:" environ environ
 
@@ -10,13 +11,13 @@ do local -x "$e"
 done
 
 cmd="$words[1]"
+cpp='_comp_priv_prefix=( $cmd -n ${(kv)opt_args[(I)-u]} )'
 _arguments -s -S -A '-*' : \
-  - optL \
-  '-L[clear any persisted authorizations]' \
-  - default \
-  '-a+[specify authentication style]:authentication style' \
-  '(-n -s)-C+[check config file and report on command matching]:config:_files' \
-  '(-C)-n[non-interactive: fail rather than prompt for a password]' \
-  '(-C *)-s[run a shell]' \
-  '-u+[run command as specified user]:user:_users' \
-  '*::arguments:{ _comp_priv_prefix=( $cmd -n ${(kv)opt_args[-u]} ) ; _normal }'
+  '(: * -)-L[clear any persisted authorizations]' \
+  '(-L)-a+[specify authentication style]:authentication style' \
+  '(-L -n -s)-C+[check config file and report on command matching]:config:_files' \
+  '(-C -L)-n[non-interactive: fail rather than prompt for a password]' \
+  '(-C -L *)-s[run a shell]' \
+  '(-L)-u+[run command as specified user]:user:_users' \
+  "(-)1: :{ $cpp; _command_names -e }" \
+  "*:: :{ $cpp; _normal }"
diff --git a/Completion/Unix/Command/_sudo b/Completion/Unix/Command/_sudo
index 41e32cbae..e3d12d72f 100644
--- a/Completion/Unix/Command/_sudo
+++ b/Completion/Unix/Command/_sudo
@@ -2,9 +2,9 @@
 
 setopt localoptions extended_glob
 
-local environ e cmd
-local -a args
-local -a _comp_priv_prefix
+local environ e cmd cpp
+local -a args _comp_priv_prefix
+local -A opt_args
 
 zstyle -a ":completion:${curcontext}:" environ environ
 
@@ -42,6 +42,10 @@ if [[ $service = sudoedit ]] || (( $words[(i)-e] < $words[(i)^(*sudo|-[^-]*)] ))
   args=( -A "-*" $args '!(-V --version -h --help)-e' '*:file:_files' )
 else
   cmd="$words[1]"
+  cpp='_comp_priv_prefix=(
+    $cmd -n
+    ${(kv)opt_args[(I)(-[ugHEP]|--(user|group|set-home|preserve-env|preserve-groups))]}
+  )'
   args+=(
     '(-e --edit 1 *)'{-e,--edit}'[edit files instead of running a command]' \
     '(-s --shell)'{-s,--shell}'[run shell as the target user; a command may also be specified]' \
@@ -51,8 +55,8 @@ else
     '(-E -i --login -s --shell -e --edit)--preserve-env=-[preserve user environment when running command]::environment variable:_sequence _parameters -g "*export*"' \
     '(-H --set-home -i --login -s --shell -e --edit)'{-H,--set-home}"[set HOME variable to target user's home dir]" \
     '(-P --preserve-groups -i -login -s --shell -e --edit)'{-P,--preserve-groups}"[preserve group vector instead of setting to target's]" \
-    '(-)1:command: _command_names -e'
-    '*::arguments:{ _comp_priv_prefix=( $cmd -n ${(kv)opt_args[(I)(-[ugHEP]|--(user|group|set-home|preserve-env|preserve-groups))]} ) ; _normal }'
+    "(-)1: :{ $cpp; _command_names -e }"
+    "*:: :{ $cpp; _normal }"
   )
 fi
 
diff --git a/Completion/Zsh/Type/_command_names b/Completion/Zsh/Type/_command_names
index cd630b7a4..b1c35f013 100644
--- a/Completion/Zsh/Type/_command_names
+++ b/Completion/Zsh/Type/_command_names
@@ -41,11 +41,24 @@ fi
 args=( "$@" )
 
 local -a cmdpath
-if zstyle -a ":completion:${curcontext}" command-path cmdpath &&
-   [[ $#cmdpath -gt 0 ]]
-then
+
+zstyle -a ":completion:${curcontext}" command-path cmdpath
+
+# Using the current PATH doesn't necessarily make sense when completing commands
+# to tools like sudo, which might set a different one. A common issue is that
+# /**/sbin appear in the PATH used by the tool, but not in the one used by the
+# unprivileged user who calls it. To do the right thing in the most common
+# cases, we'll simply ensure that the sbin variants always appear here when not
+# otherwise overridden (bash-completion's _sudo does something similar)
+if (( ! $#cmdpath && $#_comp_priv_prefix )); then
+  cmdpath=( $path ${path/%\/bin//sbin} )
+  cmdpath=( ${(u)^cmdpath}(/-N) )
+fi
+
+if (( $#cmdpath )); then
   local -a +h path
   local -A +h commands
   path=( $cmdpath )
 fi
+
 _alternative -O args "$defs[@]"


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-13  1:21               ` sudo autocompletion dana
@ 2020-02-13  1:29                 ` Bart Schaefer
  2020-02-15 22:22                 ` Andrey Butirsky
  1 sibling, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-02-13  1:29 UTC (permalink / raw)
  To: dana; +Cc: Oliver Kiddle, Zsh hackers list, Daniel Shahaf

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On Wed, Feb 12, 2020, 5:21 PM dana <dana@dana.is> wrote:

>
> PS: This does not fix `su -c` — _su doesn't set _c_p_p, presumably because
> it
> always prompts for a password. But since _c_p_p is passed directly to
> eval, we
> *could* make it set _c_p_p=( '' ), which would trick _command_names into
> doing
> the right thing. Is that too silly?
>

Compared to some of the other things we do?  No.  Just be sure not to
include a comment about it so it's just as mysterious as most of those
other tricks.  (wink)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-13  1:21               ` sudo autocompletion dana
  2020-02-13  1:29                 ` Bart Schaefer
@ 2020-02-15 22:22                 ` Andrey Butirsky
  2020-02-15 22:48                   ` dana
  1 sibling, 1 reply; 15+ messages in thread
From: Andrey Butirsky @ 2020-02-15 22:22 UTC (permalink / raw)
  To: zsh-workers

Hello dana,
seems the patches were not included to the 5.8 release. Does it mean 
they are not ready yet, and can we hope they will be included eventually?

On 13.02.2020 04:21, dana wrote:
> I made some related changes here that i can break out into separate patches if
> it makes it easier. But this is the summary:
>
> ....
>
>
> diff --git a/Completion/Solaris/Command/_pfexec b/Completion/Solaris/Command/_pfexec
> index 2519c3cdc..fc2bca835 100644
> --- a/Completion/Solaris/Command/_pfexec
> +++ b/Completion/Solaris/Command/_pfexec
> ....



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-15 22:22                 ` Andrey Butirsky
@ 2020-02-15 22:48                   ` dana
  2020-03-11 21:57                     ` dana
  0 siblings, 1 reply; 15+ messages in thread
From: dana @ 2020-02-15 22:48 UTC (permalink / raw)
  To: Andrey Butirsky; +Cc: Zsh hackers list

On 15 Feb 2020, at 16:22, Andrey Butirsky <butirsky@gmail.com> wrote:
> seems the patches were not included to the 5.8 release. Does it mean they
> are not ready yet, and can we hope they will be included eventually?

Yeah, we had already committed to the release date, and since it deals with
lower-level functions it felt slightly risky to merge it with so little time
left, so i kept it back.

It'll be one of the first things in (along with the minor _su addition we
discussed) once i'm sure there's nothing catastrophically wrong with 5.8.

Whether it will be released very soon, i'm not sure yet.

dana


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-02-15 22:48                   ` dana
@ 2020-03-11 21:57                     ` dana
  2020-03-12 21:51                       ` Andrey Butirsky
  0 siblings, 1 reply; 15+ messages in thread
From: dana @ 2020-03-11 21:57 UTC (permalink / raw)
  To: Andrey Butirsky; +Cc: Zsh hackers list

On 15 Feb 2020, at 16:48, dana <dana@dana.is> wrote:
> It'll be one of the first things in (along with the minor _su addition we
> discussed) once i'm sure there's nothing catastrophically wrong with 5.8.

I've merged this with one or two minor alterations, mainly the addition of the
_c_p_p=( '' ) hack we discussed for _su (workers/45424). Sorry for the delay

dana


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: sudo autocompletion
  2020-03-11 21:57                     ` dana
@ 2020-03-12 21:51                       ` Andrey Butirsky
  0 siblings, 0 replies; 15+ messages in thread
From: Andrey Butirsky @ 2020-03-12 21:51 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

On 3/12/20 12:57 AM, dana wrote:
> On 15 Feb 2020, at 16:48, dana <dana@dana.is> wrote:
>> It'll be one of the first things in (along with the minor _su addition we
>> discussed) once i'm sure there's nothing catastrophically wrong with 5.8.
> I've merged this with one or two minor alterations, mainly the addition of the
> _c_p_p=( '' ) hack we discussed for _su (workers/45424). Sorry for the delay
>
> dana
>
Many thanks! Looking forward for the next release then (and when it will 
be available for my distro) :)


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-03-12 21:52 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <912d22db-8a8f-90f2-6738-f9f395994dcb@gmail.com>
     [not found] ` <CAN=4vMqvzUTZ7bBLcbTzi-pKAVEP1xDbq=f5pLAxmffxUjTszQ@mail.gmail.com>
     [not found]   ` <1770be62-54d8-70a6-8b05-cfc98faa9b9f@gmail.com>
     [not found]     ` <20200210030219.527a3ccf@tarpaulin.shahaf.local2>
     [not found]       ` <ADE72275-1311-44BE-9B1D-5E617E3D9F94@gmail.com>
2020-02-10 17:13         ` sudo autocompletion dana
2020-02-10 17:40           ` Peter Stephenson
2020-02-10 18:57             ` dana
2020-02-10 19:20           ` Daniel Shahaf
2020-02-11 10:12             ` Oliver Kiddle
2020-02-11 10:28               ` Setting/Querying cache-policy (was: Re: sudo autocompletion) Daniel Shahaf
2020-02-12 16:51                 ` dana
2020-02-13  1:21               ` sudo autocompletion dana
2020-02-13  1:29                 ` Bart Schaefer
2020-02-15 22:22                 ` Andrey Butirsky
2020-02-15 22:48                   ` dana
2020-03-11 21:57                     ` dana
2020-03-12 21:51                       ` Andrey Butirsky
2020-02-10 22:05           ` Andrey Butirsky
2020-02-10 23:02             ` dana

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git