Re: PATCH: completion for file descriptors

Re: PATCH: completion for file descriptors

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> > 
> > The function moving will happen quite shortly before 4.0, I think. And
> > since I even added the BSD stuff, I think everyone should just go
> > ahead and add system specific completions like these (all functions
> > they think are fit to be exposed, that is). It might help us  to find
> > the best way for the final ordering, actually. I hope.
> 
> Okay, I've added the AIX completions. I've cited 10857 as the patch -
> there didn't seem any point in resending them in a proper patch although
> I actually made a few minor changes (using _wanted without &&).
> 
> What about completions for other applications which are not system
> specific but are not going to be of much use to most people. For
> example, I have a number of completions for Rational Apex commands.
> Maybe we could have an Apps directory which could contain further
> directories for such things as Apex and also things like rpm maybe?

I normally prefer flat directory structures but in this case: yes,
sounds good.

Hm, if the final version still looks the same we could also think
about Core/Main (_main_complete, _tags and friends), Core/Completer,
Core/Utility (for things like _arguments), Core/Foo (can't think of a
name; for _pids, _hosts, ...).

There are now already 245 completion functions. Whew.

Bye
 Sven


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

Re: PATCH: completion for file descriptors

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> The function moving will happen quite shortly before 4.0, I think. And
> since I even added the BSD stuff, I think everyone should just go
> ahead and add system specific completions like these (all functions
> they think are fit to be exposed, that is). It might help us  to find
> the best way for the final ordering, actually. I hope.

Okay, I've added the AIX completions. I've cited 10857 as the patch -
there didn't seem any point in resending them in a proper patch although
I actually made a few minor changes (using _wanted without &&).

What about completions for other applications which are not system
specific but are not going to be of much use to most people. For
example, I have a number of completions for Rational Apex commands.
Maybe we could have an Apps directory which could contain further
directories for such things as Apex and also things like rpm maybe?

Oliver

Re: PATCH: completion for file descriptors

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > The other stuff is harder to decide. _rpm, for example can also be
> > useful on non-Linux systems. I don't know debian, but I guess the
> > commands from that directory can be useful elsewhere, too. So maybe we
> > should package the functions in a way that reflects what the commands
> > do (network, package-managers, ...).
> 
> That is a bit more diffcult. I think I would prefer to stick to
> directories which group together commands which users will generally
> have all or none of as it is easier to specify whether you want a whole
> directory than to pick and choose from specific commands taking each on
> their own. I expect that it is fairly rare for someone to use rpm on
> something other than Linux.

The folks around here use rpm even under Solaris...

> Would there be problems involved in making
> the installation of the functions intelligently only pick out
> completions for commands which exist on the system?

For one, the update thing Thomas mentioned. And then people may have
different paths, the net may be heterogeneous...

> ...
> 
> I've attached my AIX specific completions. I haven't put them in cvs or
> anything but when you (or whoever) come to sort out the directories, a
> place could be found for them (and those FreeBSD ones someone sent
> yesterday). I've actually got a few more AIX (and IRIX) completions but
> they are very old (pre-_arguments) and could really do with a rewrite.

The function moving will happen quite shortly before 4.0, I think. And 
since I even added the BSD stuff, I think everyone should just go
ahead and add system specific completions like these (all functions
they think are fit to be exposed, that is). It might help us  to find
the best way for the final ordering, actually. I hope.

Bye
 Sven


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

Re: PATCH: completion for file descriptors

[Thomas Köhler]

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

On Thu, Apr 20, 2000 at 11:19:50AM +0200,
Oliver Kiddle <opk@u.genie.co.uk> wrote:
> Sven Wischnowsky wrote:
> 
> > Yes, function moving and ordering before 4.0...
> What you suggest for the basic stuff sounds good to me.
> > The other stuff is harder to decide. _rpm, for example can also be
> > useful on non-Linux systems. I don't know debian, but I guess the
> > commands from that directory can be useful elsewhere, too. So maybe we
> > should package the functions in a way that reflects what the commands
> > do (network, package-managers, ...).
> That is a bit more diffcult. I think I would prefer to stick to
> directories which group together commands which users will generally
> have all or none of as it is easier to specify whether you want a whole
> directory than to pick and choose from specific commands taking each on
> their own. I expect that it is fairly rare for someone to use rpm on
> something other than Linux. Would there be problems involved in making
> the installation of the functions intelligently only pick out
> completions for commands which exist on the system?

Well, yes. I'd see a problem if zsh wouldn't install ssh completion
because there is no ssh installed (just because someone forgot to
install it), ssh gets installed later, and the completion is not there.
(anything besides ssh may be used as an example)
One could argue "then do a make install again", but what about people
who are low on disk space and just have deleted the source tree again?
Download again. Bad.

CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: PATCH: completion for file descriptors

[Oliver Kiddle]

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

Sven Wischnowsky wrote:

> Yes, function moving and ordering before 4.0...

What you suggest for the basic stuff sounds good to me.

> The other stuff is harder to decide. _rpm, for example can also be
> useful on non-Linux systems. I don't know debian, but I guess the
> commands from that directory can be useful elsewhere, too. So maybe we
> should package the functions in a way that reflects what the commands
> do (network, package-managers, ...).

That is a bit more diffcult. I think I would prefer to stick to
directories which group together commands which users will generally
have all or none of as it is easier to specify whether you want a whole
directory than to pick and choose from specific commands taking each on
their own. I expect that it is fairly rare for someone to use rpm on
something other than Linux. Would there be problems involved in making
the installation of the functions intelligently only pick out
completions for commands which exist on the system?

> (And now Andrej comes and
> says that we should put all the GNU commands on the side... which
> wouldn't work with the ordering-by-what-they-do, of course. I still
> think there should be only one function per command and we try to find
> out what to complete by investigating the environment inside the
> functions.)

I agree with you on this. It keeps things all together better than if we
say had 10 different completions for the same command on different
systems so it is easier to make useful changes affect all the different
systems where they have commonality. It is common for GNU stuff to be
installed alongside originals, sometimes in a different directory and
sometimes with a different name and it would be important to me that
completion for these works.

I've attached my AIX specific completions. I haven't put them in cvs or
anything but when you (or whoever) come to sort out the directories, a
place could be found for them (and those FreeBSD ones someone sent
yesterday). I've actually got a few more AIX (and IRIX) completions but
they are very old (pre-_arguments) and could really do with a rewrite.

Oliver

[-- Attachment #2: Aixcomps.tgz --]
[-- Type: application/x-unknown-content-type-WinZip, Size: 1662 bytes --]

Re: PATCH: completion for file descriptors

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> If put _file_descriptors in Core because
> it will be used by _redirect and because other things like _options is
> there - it can always be moved.

Yes, function moving and ordering before 4.0...

The directories we have now have mostly historical reasons and several 
functions could sensibly be moved in other directories even now.

What I would like is a more logical ordering. I haven't really thought 
about this yet, but maybe a Core with some of the functions it
contains now, a directory with functions like _arguments (not really
generating completions, only helping to add them), one directory with
all those functions that generate a certain type of matches (options,
jobs, pids, file-descriptors, etc.). And then certainly one for the
builtin commands.

The other stuff is harder to decide. _rpm, for example can also be
useful on non-Linux systems. I don't know debian, but I guess the
commands from that directory can be useful elsewhere, too. So maybe we 
should package the functions in a way that reflects what the commands
do (network, package-managers, ...).

I'd like to hear suggestions about all this. (And now Andrej comes and 
says that we should put all the GNU commands on the side... which
wouldn't work with the ordering-by-what-they-do, of course. I still
think there should be only one function per command and we try to find 
out what to complete by investigating the environment inside the
functions.)


Bye
 Sven


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

PATCH: completion for file descriptors

[Oliver Kiddle]

Here is the completion for file descriptors which was discussed during
the day along with a few small changes to _print to use it and to handle
-p only when the is a coprocess. Can anyone see any problems or
alternatives to my fallback method of finding links of using ls -l piped
into sed? The stat module works well but I didn't want to use it if it
wasn't loaded because it isn't there by default. On IRIX, I seem to get
all 10 file descriptors listed regardless and I can't see a way round
it, not that it matters much. If put _file_descriptors in Core because
it will be used by _redirect and because other things like _options is
there - it can always be moved.

Oliver

Index: Completion/Builtins/_print
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Builtins/_print,v
retrieving revision 1.1
diff -r1.1 _print
3c3
< local state expl line eflag
---
> local state expl line eflag pflag
7a8,11
> # -p flag only relevant if we have a coprocess
> (:>&p) 2>/dev/null &&
>   pflag='(-s -u -z)-p[print arguments to input of coprocess]'
> 
21,22c25
<   '(-s -p -z)-u+[specify file-descriptor to print arguments to]:file-descritor' \
<   '(-s -u -z)-p[print arguments to input of coprocess]' \
---
>   '(-s -p -z)-u+[specify file-descriptor to print arguments to]:file-descriptor:_file_descriptors' \
26c29
<   $eflag '*:default:_default'
---
>   $pflag $eflag '*:default:_default'
Index: Completion/Core/_file_descriptors
===================================================================
RCS file: _file_descriptors
diff -N _file_descriptors
0a1,23
> #autoload
> 
> local i fds expl list link
> 
> for i in {0..9}; [[ -e /dev/fd/$i ]] && fds=( ${fds[@]} $i )
> 
> if zstyle -T ":completion:${curcontext}" verbose && [[ -e /proc/$$/fd ]]; then
>   if zmodload -e zsh/stat; then
>     for i in "${fds[@]}"; do
>       stat +link -A link /proc/$$/fd/$i
>       list=( ${list[@]} "$i -- ${link[1]}" )
>     done
>   elif (( $+commands[readlink] )); then
>     for i in "${fds[@]}"; list=( ${list[@]} "$i -- $(readlink /proc/$$/fd/$i)" )
>   else
>     for i in "${fds[@]}"; do
>       list=( ${list[@]} "$i -- $(ls -l /proc/$$/fd/$i|sed 's/.*-> //' )" )
>     done
>   fi
>   _wanted file-descriptors expl 'file descriptors' compadd "$@" -d list - "$fds[@]"  
> else
>   _wanted file-descriptors expl 'file descriptors' compadd "$@" - "$fds[@]"
> fi