chown completion

chown completion

[Oliver Kiddle]

Below is a patch against _chown which I've not committed. It adds a
certain amount of intelligence to reduce the number of matches. It
restricts the files matched to just those for which the chown command
would make sense, i.e. excluding those for which the ownership would be
unchanged by the chown command. I've got a few questions though before
I either finish or abandon this.

How could I avoid the two consecutive _files calls to specify files
where either the user is not $usr or the group is not $grp?
*(^u.$usr.g.$grp.) matches files where user is not $usr AND group is
not $grp.

For non-root users, only the groups listed by the groups command are
completed first. I think that it is only some configurations which have
this restriction on chown. Does anyone have any ideas on how to detect
this? Does the groups command work the same on other unices?

It could also restrict files to those owned by the current user (unless
it is root) as you can't chown other people's files.

Any ideas on how it should deal with invalid users or groups? As it is,
it displays `_path_files:330: unknown user' which isn't too bad really.
This also doesn't currently handle users and groups being specified
numerically but that should be fairly easy to do.

Incidentally, if I separate the user/groups with a colon, not a dot in
the glob, I get this message:
    _path_files:330: bad pattern: *(^g:users

Oliver

--- _chown      Mon Apr  2 12:46:20 2001
+++ _chown      Fri May  4 17:42:47 2001
@@ -1,10 +1,13 @@
 #compdef chown chgrp
 
-local suf
+local suf usr grp expl ret=1
 
 if [[ CURRENT -eq 2 || CURRENT -eq 3 && $words[CURRENT-1] = -* ]]; then
   if [[ $service = chgrp ]] || compset -P '*[:.]'; then
-    _groups
+    if (( GID && $+commands[groups] )); then
+      _wanted groups expl 'group' compadd $(groups) && return 0
+    fi
+    _groups && return 0
   else
     if [[ $OSTYPE = (solaris*|hpux*) ]]; then
       suf=':'
@@ -12,8 +15,21 @@
       suf='.'
     fi
     compset -S '.*' && unset suf
-    _users -S "$suf" -q
+    _users -S "$suf" -q && return 0
   fi
 else
-  _files
+  usr=${words[CURRENT-1]%%[.:]*}
+  grp=${words[CURRENT-1]#*[.:]}
+
+  if [[ $service = chgrp ]]; then
+    _files -g "*(^g.$grp.)" && return 0
+  elif [[ $usr = $grp ]]; then
+    _files -g "*(^u.$usr.)" && return 0
+  else
+    _files -g "*(^u.$usr.)" && ret=0
+    _files -g "*(^g.$grp.)" && ret=0
+  fi
+  _files && ret=0
 fi
+
+return ret

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: chown completion

[Bart Schaefer]

On May 4,  6:18pm, Oliver Kiddle wrote:
> Subject: chown completion
> 
> How could I avoid the two consecutive _files calls to specify files
> where either the user is not $usr or the group is not $grp?
> *(^u.$usr.g.$grp.) matches files where user is not $usr AND group is
> not $grp.

Comma-separated list:

	*(^u.$usr.,^g.$grp.)

> It could also restrict files to those owned by the current user (unless
> it is root) as you can't chown other people's files.

True.

> Any ideas on how it should deal with invalid users or groups? As it is,
> it displays `_path_files:330: unknown user' which isn't too bad really.

That line in _path_files really should be

	eval 'tmp1=( $~tmp1 )' 2>/dev/null

Most expansion errors will be caught before it gets that far, but not
those that result from "mistakes" in the globbing flags.  On the other
hand, if we'd suppressed that error message, you'd never have found:

> Incidentally, if I separate the user/groups with a colon, not a dot in
> the glob, I get this message:
>     _path_files:330: bad pattern: *(^g:users

I think this is related to the pattern that attempts to rewrite the glob
flags to implement the file-sort style.  I've had trouble with that before.

> +    if (( GID && $+commands[groups] )); then

Shouldn't you be using EGID there?

I don't know the answers to any of the other questions, sorry.

Re: chown completion

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> For non-root users, only the groups listed by the groups command are
> completed first. I think that it is only some configurations which have
> this restriction on chown. Does anyone have any ideas on how to detect
> this?

No, sorry.

> Does the groups command work the same on other unices?

At least it does on this True 64 Unix here.

> ...
> 
> Any ideas on how it should deal with invalid users or groups? As it is,
> it displays `_path_files:330: unknown user' which isn't too bad really.

For users one could test $+userdirs[<name>].

> ...
> 
> Incidentally, if I separate the user/groups with a colon, not a dot in
> the glob, I get this message:
>     _path_files:330: bad pattern: *(^g:users

That was caused by _files which has to put backslashes before the colons
in the pattern it gets and later has to double the number of
backslashes.  There I forgot the `g' before the `s' modifier.


Bart Schaefer wrote:

> ...
>
> That line in _path_files really should be
> 
> 	eval 'tmp1=( $~tmp1 )' 2>/dev/null

Hm.  We should then at least do something like

  eval 'tmp1=( $~tmp1 )' 2>/dev/null || ...

where the `...' either returns with a non-zero value or uses _message to
say that the pattern was badly formed.  Or both.  Or make it selectable
with an option to _path_files.  Or something.


Bye
  Sven

Index: Completion/Unix/Type/_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_files,v
retrieving revision 1.2
diff -u -r1.2 _files
--- Completion/Unix/Type/_files	2001/05/03 17:07:29	1.2
+++ Completion/Unix/Type/_files	2001/05/07 09:02:28
@@ -52,7 +52,7 @@
 
 tried=()
 for def in "$pats[@]"; do
-  eval "def=( ${${def:s/\\:/\\\\\\\\\\\\:}//(#b)([][()|*?^#~<>])/\\${match[1]}} )"
+  eval "def=( ${${def:gs/\\:/\\\\\\\\\\\\:}//(#b)([][()|*?^#~<>])/\\${match[1]}} )"
   for sdef in "$def[@]"; do
 
     tag="${${sdef#*[^\\]:}%%:*}"

-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de