functions/Completion/Linux/_modutils

functions/Completion/Linux/_modutils

[sergio]

Hello.

When i'm not root  modprobe is not in my path, so
in case "all_modules)" "modules" will be empty:

  all_modules)
    modules=( ${${${${(f)"$(_call_program modules
${(M)words[1]##*/}modprobe -l 2>/dev/null)"}:#}##*/}%%.*} )

words --- what this?

with
modules=( ${${${${(f)"$(_call_program modules
${(M)words[1]##*/}/sbin/modprobe -l 2>/dev/null)"}:#}##*/}%%.*} )
all works fine

-- 
sergio

Re: functions/Completion/Linux/_modutils

[Bart Schaefer]

On May 13,  8:19pm, sergio wrote:
}
} When i'm not root  modprobe is not in my path, so
} in case "all_modules)" "modules" will be empty:

When completing for what?  An example command line would be helpful.

}   all_modules)
}     modules=( ${${${${(f)"$(_call_program modules
} ${(M)words[1]##*/}modprobe -l 2>/dev/null)"}:#}##*/}%%.*} )
} 
} words --- what this?

It's the command line broken out into an array of the $IFS-separated
substrings.  Each such substring is called a "word" in the semi-formal
shell grammar described in the manual page.

So ${(M)words[1]##*/} should be the path prefix of the command name.
For example, if you are completing after /sbin/lsmod, then that
expansion is /sbin/ which is then prefixed to modprobe.  The idea is
that if modprobe isn't in your path, the best place to look for it
is in the same place as whatever other command (assumed also not to
be in your path and therefore a full path name) you are completing.

} with
} modules=( ${${${${(f)"$(_call_program modules
} ${(M)words[1]##*/}/sbin/modprobe -l 2>/dev/null)"}:#}##*/}%%.*} )
} all works fine

Except if you complete after /sbin/rmmod, the completion will try to
run /sbin//sbin/modprobe and break.

Re: functions/Completion/Linux/_modutils

[sergio]

Bart Schaefer wrote:
> On May 13,  8:19pm, sergio wrote:
> }
> } When i'm not root  modprobe is not in my path, so
> } in case "all_modules)" "modules" will be empty:
> 
> When completing for what?  An example command line would be helpful.
sudo modprobe <TAB> should list all available modules (may be all not
loaded modules) but it doesn't.

-- 
sergio

Re: functions/Completion/Linux/_modutils

[Peter Stephenson]

On Wed, 14 May 2008 18:16:37 +0400
sergio <zsh@sergio.spb.ru> wrote:
> Bart Schaefer wrote:
> > On May 13,  8:19pm, sergio wrote:
> > }
> > } When i'm not root  modprobe is not in my path, so
> > } in case "all_modules)" "modules" will be empty:
> > 
> > When completing for what?  An example command line would be helpful.
>
> sudo modprobe <TAB> should list all available modules (may be all not
> loaded modules) but it doesn't.

Shouldn't the fix be something like this?

By the way, isn't that "_files" completion three lines below screwy?
Shouldn't it be looking for .ko files (or possibly .o files depending on
the version)?

Index: Completion/Linux/Command/_modutils
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Linux/Command/_modutils,v
retrieving revision 1.6
diff -u -r1.6 _modutils
--- Completion/Linux/Command/_modutils	12 Aug 2007 09:04:52 -0000	1.6
+++ Completion/Linux/Command/_modutils	14 May 2008 15:11:48 -0000
@@ -73,7 +73,7 @@
   ;;
 
   all_modules)
-    modules=( ${${${${(f)"$(_call_program modules ${(M)words[1]##*/}modprobe -l 2>/dev/null)"}:#}##*/}%%.*} )
+    modules=( ${${${${(f)"$(path=($path /sbin); _call_program modules ${(M)words[1]##*/}modprobe -l 2>/dev/null)"}:#}##*/}%%.*} )
     _tags files modules
     while _tags; do
       _requested files expl "module file"  _files && ret=0




-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: functions/Completion/Linux/_modutils

[Bart Schaefer]

On May 14,  6:16pm, sergio wrote:
}
} sudo modprobe <TAB> should list all available modules (may be all not
} loaded modules) but it doesn't.

Aha.  So the problem is with the completion for sudo, not the completion
for modprobe.  Calling "_normal" is not adequate when the environment in
which the command will run is not the same as the environment in which
the completer is running.

I can't advocate breaking _modutils (and everything else, one at a time)
for all ordinary cases, just to fix this for "sudo".  So how about this?

% zstyle :complete:sudo: environ \
    PATH="/sbin:/usr/sbin:$PATH" HOME="/root"
% sudo modprobe <TAB>

The environ style is an array of VAR=value which are exported into the
local environment before the completion for the target command is
invoked.  If this looks OK and nobody beats me to it, I'll add some
documentation, too.

Of course it would be preferable if "sudo -H /tmp/foo" would export
HOME=/tmp/foo, and if the style could be specialized to the target
user for "sudo -u" and so on, but I'm not prepared to go that far
overboard just now.

Index: Completion/Unix/Command/_sudo
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Completion/Unix/Command/_sudo,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 _sudo
--- zsh-4.3/Completion/Unix/Command/_sudo	9 Apr 2001 20:14:09 -0000	1.1.1.1
+++ _sudo	14 May 2008 15:22:23 -0000
@@ -1,5 +1,12 @@
 #compdef sudo
 
+local curcontext="$curcontext" environ e
+zstyle -a "$curcontext" environ environ
+
+for e in "${environ[@]}"
+do local -x "$e"
+done
+
 _arguments \
        '-V[show version]' \
        '-l[list allowed commands]' \

Re: functions/Completion/Linux/_modutils

[sergio]

Peter Stephenson wrote:

> Shouldn't the fix be something like this?
> $(path=($path /sbin)

hmm..
in root's path /sbin states before /bin
so if i have two modprobes (in /bin and in /sbin) zsh will list modules
with /bin/modprobe, while /sbin/modprobe will really executed by sudo

i can't find any logic where zsh search command to complete after sudo
(when i type sudo <TAB>)
may be it will be more correctly to make some changes in sudo completion?

> By the way, isn't that "_files" completion three lines below screwy?
> Shouldn't it be looking for .ko files (or possibly .o files depending on
> the version)?
I'm newbie in zsh ): I don't understand this lines..

-- 
sergio

Re: functions/Completion/Linux/_modutils

[sergio]

Bart Schaefer wrote:

> I can't advocate breaking _modutils (and everything else, one at a time)
> for all ordinary cases, just to fix this for "sudo".  So how about this?
> 
> % zstyle :complete:sudo: environ \
>     PATH="/sbin:/usr/sbin:$PATH" HOME="/root"
> % sudo modprobe <TAB>
Hmm.. How zsh searches command when I type 'sudo <TAB>'
It will be better to get $path from that logic.

> Of course it would be preferable if "sudo -H /tmp/foo" would export
> HOME=/tmp/foo, and if the style could be specialized to the target
> user for "sudo -u" and so on, but I'm not prepared to go that far
> overboard just now.
But it's not very difficult.. ? (:

-- 
sergio

Re: functions/Completion/Linux/_modutils

[Bart Schaefer]

On May 14,  8:19pm, sergio wrote:
}
} > % zstyle :complete:sudo: environ \
} >     PATH="/sbin:/usr/sbin:$PATH" HOME="/root"
} > % sudo modprobe <TAB>
} Hmm.. How zsh searches command when I type 'sudo <TAB>'
} It will be better to get $path from that logic.

That just calls _command_names, which doesn't do anything magical at
all; in fact I'd expect it not to find modprobe if calling modprobe
later will fail for path reasons.  The path needs to be set where I
set it in that patch, before any completers are invoked.

} > Of course it would be preferable if "sudo -H /tmp/foo" would export
} > HOME=/tmp/foo, and if the style could be specialized to the target
} > user for "sudo -u" and so on, but I'm not prepared to go that far
} > overboard just now.
} But it's not very difficult.. ? (:

It means dismantling the simple _arguments call into something that uses
state transitions to capture values as each argument is examined.

I don't believe that's worth the effort (it's certainly not worth *my*
effort, as I'm perfectly happy with the way it's been working for the
last seven years).

Re: functions/Completion/Linux/_modutils

[Clint Adams]

On Wed, May 14, 2008 at 09:40:46AM -0700, Bart Schaefer wrote:
> That just calls _command_names, which doesn't do anything magical at
> all; in fact I'd expect it not to find modprobe if calling modprobe
> later will fail for path reasons.  The path needs to be set where I
> set it in that patch, before any completers are invoked.

Debian has been shipping this in the global zshrc, which could lead to
the situation you describe.

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

I have all the sbins included in my $path, so I've never noticed.

Re: functions/Completion/Linux/_modutils

[Bart Schaefer]

On Thu, May 15, 2008 at 5:16 AM, Clint Adams <schizo@debian.org> wrote:
>
> zstyle ':completion:*:sudo:*' command-path /usr/local/sbin /usr/local/bin \
>                             /usr/sbin /usr/bin /sbin /bin /usr/X11R6/bin

OK, so maybe the right thing is to ignore my patch and have _sudo grab
the value of *that* style and export it.  (Still doesn't address the
-H and -u things I mentioned.)

Any opinions?  PWS?  Even if we keep something like my patch, should
the context be changed to prefix it with ":completion" ?

Re: functions/Completion/Linux/_modutils

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Thu, May 15, 2008 at 5:16 AM, Clint Adams <schizo@debian.org> wrote:
> >
> > zstyle ':completion:*:sudo:*' command-path /usr/local/sbin /usr/local/bin \
> >                             /usr/sbin /usr/bin /sbin /bin /usr/X11R6/bin
> 
> OK, so maybe the right thing is to ignore my patch and have _sudo grab
> the value of *that* style and export it.

Sounds pretty sensible, but we definitely want to document that this
happens for security reasons.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: functions/Completion/Linux/_modutils

[Peter Stephenson]

On Thu, 15 May 2008 18:00:35 +0100
Peter Stephenson <pws@csr.com> wrote:
> "Bart Schaefer" wrote:
> > On Thu, May 15, 2008 at 5:16 AM, Clint Adams <schizo@debian.org> wrote:
> > >
> > > zstyle ':completion:*:sudo:*' command-path /usr/local/sbin /usr/local/bin \
> > >                             /usr/sbin /usr/bin /sbin /bin /usr/X11R6/bin
> > 
> > OK, so maybe the right thing is to ignore my patch and have _sudo grab
> > the value of *that* style and export it.
> 
> Sounds pretty sensible, but we definitely want to document that this
> happens for security reasons.

Thinking more, security surely isn't an issue after all.  Nothing is
actually being run here as superuser, and you're only using the
command-path (as the current user) that the current user has explicitly
told you it's OK to use.  So there's no more problem with Trojans than with
any other use of paths by the shell.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070