Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Clint Adams]

> Trying to tab complete 'sudo modprobe' never works, as modprobe is
> never added into the list of completions.

Would it be better to do something like this

(PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
; rehash; print $commands)

or glob for executable files in that path or is there a better solution?

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Bart Schaefer]

On Apr 28,  9:04am, Clint Adams wrote:
}
} (PATH="root's:path:for:sudo"; rehash; print $commands)
} 
} or glob for executable files in that path or is there a better solution?

How about:

	local -a +h commands path
	path=( ... )
	compadd -a commands

The more interesting question, I think, would be where to get an accurate
value for root's sudo path without first being root.

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Clint Adams]

> How about:
> 
> 	local -a +h commands path
> 	path=( ... )
> 	compadd -a commands
> 
> The more interesting question, I think, would be where to get an accurate
> value for root's sudo path without first being root.

Well, you could do the equivalent of "strings =sudo | grep sbin:", but
that seems ugly and error-prone.

I'd suggest using a sane default which can be overridden with zstyle.

I have a sneaking suspicion that sudo isn't the only command for which
it would make sense to override the path for _command_names though.

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Oliver Kiddle]

Clint Adams wrote:
> 
> Well, you could do the equivalent of "strings =sudo | grep sbin:", but
> that seems ugly and error-prone.

That wouldn't work on my system here. It looks like there is a
"SECURE_PATH" compile option to sudo which needs to be enabled before it
uses a different path:

% PATH=/usr/bin sudo printenv PATH
/usr/bin

Out of interest, is there any way to run a process detached from the tty?
(the above sometimes prompts for a password.)

> I have a sneaking suspicion that sudo isn't the only command for which
> it would make sense to override the path for _command_names though.

If you use a style, give it a generic sounding name then. Perhaps it
could be looked up from _command_names instead of _sudo. Keep in mind
that people might want to do things like add to the existing path or
remove `.'.

Oliver

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Clint Adams]

> That wouldn't work on my system here. It looks like there is a
> "SECURE_PATH" compile option to sudo which needs to be enabled before it
> uses a different path:
> 
> % PATH=/usr/bin sudo printenv PATH
> /usr/bin

So probably the only reasonable thing to do is to default to current
PATH and I can put the appropriate overriding zstyle in the global zshrc
of the Debian package, or at least a note about it.

> Out of interest, is there any way to run a process detached from the tty?
> (the above sometimes prompts for a password.)

Does
sudo setsid sleep 600
do what you mean?

> If you use a style, give it a generic sounding name then. Perhaps it
> could be looked up from _command_names instead of _sudo. Keep in mind
> that people might want to do things like add to the existing path or
> remove `.'.

So... it should be eval'd?

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Bart Schaefer]

On Apr 30, 11:39am, Clint Adams wrote:
}
} > If you use a style, give it a generic sounding name then. Perhaps it
} > could be looked up from _command_names instead of _sudo. Keep in mind
} > that people might want to do things like add to the existing path or
} > remove `.'.
} 
} So... it should be eval'd?

If it needs eval-ing, that can be done with "zstyle -e ...".

I think he means that it should have several possible values, e.g. (just
throwing out ideas):

zstyle ':completion:*:sudo:*' command-path delete . .. '../*'

zstyle ':completion:*:sudo:*' command-path append /usr/local/bin /opt/bin

zstyle ':completion:*:sudo:*' command-path prepend ~/bin /usr/local/bin

zstyle ':completion:*:sudo:*' command-path assign /bin /usr/bin /usr/sbin

(This begs the question of what to do if you want to add things at both
the end and the beginning.)

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Clint Adams]

This is how to achieve the equivalent effects with the patch at the
bottom, which could probably use some deuglification/optimization.
Should I commit?

> zstyle ':completion:*:sudo:*' command-path delete . .. '../*'

zstyle -e ':completion:*:sudo:*' command-path 'reply=(${path:#(.|..|../*})'

> zstyle ':completion:*:sudo:*' command-path append /usr/local/bin /opt/bin

zstyle -e ':completion:*:sudo:*' command-path 'reply=($path /usr/local/bin /opt/bin)'

> zstyle ':completion:*:sudo:*' command-path prepend ~/bin /usr/local/bin

zstyle -e ':completion:*:sudo:*' command-path 'reply=(~/bin /usr/local/bin $path)'

> zstyle ':completion:*:sudo:*' command-path assign /bin /usr/bin /usr/sbin

zstyle ':completion:*:sudo:*' command-path /bin /usr/bin /usr/sbin

> (This begs the question of what to do if you want to add things at both
> the end and the beginning.)

zstyle -e ':completion:*:sudo:*' command-path 'reply=(~/bin $path /usr/local/bin /opt/bin)'
Though I don't see the significance of path order.

Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.6
diff -u -r1.6 _command_names
--- Completion/Zsh/Type/_command_names	3 Sep 2003 10:15:35 -0000	1.6
+++ Completion/Zsh/Type/_command_names	1 May 2004 04:57:49 -0000
@@ -33,4 +33,13 @@
 
 args=( "$@" )
 
+{
+local -a oldpath
+oldpath=( $path )
+local -A +h commands
+local -a cmdpath
+zstyle -a ":completion:${curcontext}" command-path cmdpath
+local -a +h path
+[[ $#cmdpath -gt 0 ]] && path=( $cmdpath ) || path=( $oldpath )
 _alternative -O args "$defs[@]"
+}

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Bart Schaefer]

On May 1,  1:02am, Clint Adams wrote:
} Subject: Re: Bug#246305: zsh: completion for sudo doesn't add commands und
}
} This is how to achieve the equivalent effects with the patch at the
} bottom

<Nodding.>

} Should I commit?

It'd be preferable to avoid declaring "local +h" if you don't need them.
If you declare them, then zsh has to save/restore the globals, which has
the side effect of causing a rehash, etc.

So I'd suggest something like:

 local -a cmdpath
 if zstyle -a ":completion:${curcontext}" command-path cmdpath &&
    [[ $#cmdpath -gt 0 ]]
 then
   local -a +h path
   local -A +h commands
   path=( $cmdpath )	# Resets $commands as a side-effect
 fi
 _alternative -O args "$defs[@]"

Remember that "local" is function-scoped, not block-scoped, so you don't
need { } around anything, nor do the local decls have to appear in the
same if-branch as the call to _alternative.

Re: Bug#246305: zsh: completion for sudo doesn't add commands under root's path

[Clint Adams]

> So I'd suggest something like:
> 
>  local -a cmdpath
>  if zstyle -a ":completion:${curcontext}" command-path cmdpath &&
>     [[ $#cmdpath -gt 0 ]]

Okay, verbatim but for the comment.
BTW, I don't know if it's just me, but verizon.net is rejecting direct mail
to Bart.

Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.6
diff -u -r1.6 _command_names
--- Completion/Zsh/Type/_command_names	3 Sep 2003 10:15:35 -0000	1.6
+++ Completion/Zsh/Type/_command_names	1 May 2004 05:40:32 -0000
@@ -33,4 +33,12 @@
 
 args=( "$@" )
 
+local -a cmdpath
+if zstyle -a ":completion:${curcontext}" command-path cmdpath &&
+   [[ $#cmdpath -gt 0 ]]
+then
+  local -a +h path
+  local -A +h commands
+  path=( $cmdpath )
+fi
 _alternative -O args "$defs[@]"
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.174
diff -u -r1.174 compsys.yo
--- Doc/Zsh/compsys.yo	29 Feb 2004 12:09:11 -0000	1.174
+++ Doc/Zsh/compsys.yo	1 May 2004 05:40:34 -0000
@@ -1140,6 +1140,11 @@
 care should be taken to specify only commands that take a short
 time to run, and in particular to avoid any that may never terminate.
 )
+kindex(command-path, completion style)
+item(tt(command-path))(
+This is a list of directories to search for commands to complete.  The
+default for this style is the value of the special parameter tt(path).
+)
 kindex(commands, completion style)
 item(tt(commands))(
 This is used by the function completing sub-commands for the system

[OT] Mail problems (was Re: Bug#246305 ...)

[Bart Schaefer]

On May 1,  1:42am, Clint Adams wrote:
}
} BTW, I don't know if it's just me, but verizon.net is rejecting direct
} mail to Bart.

Several months ago Verizon instituted a "callback" policy -- their mail
servers wait for the MAIL FROM, then attempt to look up an MX record for
that address and make an SMTP connection to that MX.  If they connect
to the MX, they issue MAIL FROM:<> and RCPT TO:<the MAIL FROM of the
message destined for verizon> and expect a 250 OK, at which point they
hang up.

They then reject the message with a 450 temporary failure if there is no
MX (so hosts with only an A record are out of luck) or permanently with
a 550 if there was no 250 OK to their callback.

Some sysadmins consider such callbacks abusive in their own right, and
others consider them to be a sign of accept-then-bounce of worm spew, so
they configure their systems to stop answering verizon's callbacks, and
the result is that no mail can reach verizon from those domains.

I don't know what the specific situation may be for Clint.  However, I
*did* get two copies (one on-list, one direct) of the message from Clint
that is excerpted above.