Re: bash-2.04 programmable completion

Re: bash-2.04 programmable completion

[Sven Wischnowsky]

Falk Hueffner wrote:

> Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > Just found this:
> > 
> > > From: chet@nike.ins.cwru.edu (Chet Ramey)
> > > Subject: Bash-2.04 Programmable Completion message 4
> > > Date: 05 Nov 1999 00:00:00 GMT
> > > Message-ID: <991105173103.AA78566.SM@nike.ins.cwru.edu>
> > [...]
> > Two builtins `complete' and `compgen' with almost the same options,
> > functions starting with underscore, -[PS] options, COMPREPLY, arrays
> > holding names of stopped jobs and functions, etc.
> > 
> > `compgen' is lightly different from what was our `compgen', it
> > obviously just outputs the possible matches. But then -- the name.
> 
> I think it would be BAD if bash had a similar system to zsh. It would
> create confusion and increase work if one would want to use the same
> completion scripts for both shells. So we should really try to have at
> least a common base. I don't know if the two systems could be totally
> compatible, since probably bash doesn't implement some needed features
> like assiocative arrays. If this is impossible, the bash system should
> at least not look similar.
> 
> Could probably some competent person contact the bash maintainers on
> this topic?

Well... they may have read your mail already. (I got a mail from Chet
Ramey where he answered my `Are we being monitored?' with `Of course. 
Great programmers steal good ideas wherever possible.')

I don't think we can make anyone do anything just because their
completion interface looks too much like ours. And, in fact, it only
looks like a mixture of compctl and compgen. The former is what I
would like to call deprecated and the latter is already dead.

And as long as bash doesn't have all those spiffy utility functions we 
have, I don't think we'll be able to interchange completion functions. 
What might be possible (and this is more interesting for us anyway) is 
to hack something that allows us to use bash-completion functions. This
also allows me to mention again that I would like to have a shell
function named `compctl' that defines functions for the completion
system -- as the last step before removing the compctl module.
Something like this function (two of them, named `complete' and
`compgen') together with some wrapper function used to call bash-
completion-functions should probably be enough to use these functions
and help users to migrate from bash to zsh.
For several of the functions/commands this won't be needed, though,
because we have our own functions for that.

Bye
 Sven


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

Re: bash-2.04 programmable completion

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> Well... they may have read your mail already. (I got a mail from Chet
> Ramey where he answered my `Are we being monitored?' with `Of course. 
> Great programmers steal good ideas wherever possible.')

<grin> But great programmers never re-invent the wheel.  What are the
remaining valid reasons why people would prefer bash over zsh?  (I
don't count inertia as valid :-)

Hmm, maybe this should be moved to zsh-users.  Or alt.religion.sh ...

Re: bash-2.04 programmable completion

[Clint Adams]

> <grin> But great programmers never re-invent the wheel.  What are the
> remaining valid reasons why people would prefer bash over zsh?  (I
> don't count inertia as valid :-)

It's compatible enough to impersonate a POSIX /bin/sh, for one thing.

Re: bash-2.04 programmable completion

[Falk Hueffner]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Just found this:
> 
> > From: chet@nike.ins.cwru.edu (Chet Ramey)
> > Subject: Bash-2.04 Programmable Completion message 4
> > Date: 05 Nov 1999 00:00:00 GMT
> > Message-ID: <991105173103.AA78566.SM@nike.ins.cwru.edu>
> [...]
> Two builtins `complete' and `compgen' with almost the same options,
> functions starting with underscore, -[PS] options, COMPREPLY, arrays
> holding names of stopped jobs and functions, etc.
> 
> `compgen' is lightly different from what was our `compgen', it
> obviously just outputs the possible matches. But then -- the name.

I think it would be BAD if bash had a similar system to zsh. It would
create confusion and increase work if one would want to use the same
completion scripts for both shells. So we should really try to have at
least a common base. I don't know if the two systems could be totally
compatible, since probably bash doesn't implement some needed features
like assiocative arrays. If this is impossible, the bash system should
at least not look similar.

Could probably some competent person contact the bash maintainers on
this topic?

	Falk

bash-2.04 programmable completion

[Sven Wischnowsky]

Just found this:

> From: chet@nike.ins.cwru.edu (Chet Ramey)
> Subject: Bash-2.04 Programmable Completion message 4
> Date: 05 Nov 1999 00:00:00 GMT
> Message-ID: <991105173103.AA78566.SM@nike.ins.cwru.edu>
> ...
> Newsgroups: gnu.bash.bug

Some excerpts:

> ...
> # this isn't exactly right yet -- needs to skip shell functions and
> # do $PATH lookup (or do compgen -c and filter out matches that also
> # appear in compgen -A function)
> complete -c command
> 
> # could add -S '=', but that currently screws up because readline appends
> # a space unconditionally
> 
> complete -v export local readonly
> ...
> #
> # Job control builtins: fg, bg, disown, kill, wait
> # kill not done yet
> #
> 
> complete -A stopped -P '%' bg
> complete -j -P '%' fg jobs disown
> ...
> #
> # meta-completion (completion for complete/compgen)
> #
> _complete_meta_func()
> {
>         local cur prev cmd
>         COMPREPLY=()
> 
>         cmd=$1
> 
>         cur=${COMP_WORDS[COMP_CWORD]}
>         prev=${COMP_WORDS[COMP_CWORD-1]}
> 
>         if (( $COMP_CWORD <= 1 )) || [[ "$cur" == '-' ]]; then
>                 case "$cmd" in
>                 complete) COMPREPLY=(-a -b -c -d -e -f -j -k -v -u -r -p -A -G -W -P -S -X -F -C);;
>                 compgen)  COMPREPLY=(-a -b -c -d -e -f -j -k -v -u -A -G -W -P -S -X -F -C);;
>                 esac
>                 return 0
>         fi
> 
>         if [[ $prev == -A ]]; then
>                 COMPREPLY=(alias arrayvar binding builtin command directory \
> disabled enabled export file function helptopic hostname job keyword \
> running setopt shopt signal stopped variable)
>                 return 0
>         elif [[ $prev == -F ]]; then
>                 COMPREPLY=( $( compgen -A function $cur ) )
>         elif [[ $prev == -C ]]; then
>                 COMPREPLY=( $( compgen -c $cur ) )
>         else
>                 COMPREPLY=( $( compgen -c $cur ) )
>         fi
>         return 0
> }
> complete -F _complete_meta_func complete compgen
> ...
> complete -f chown ln more cat
> complete -d mkdir rmdir
> ...
> complete -f -X '!*.pl' perl perl5
> 
> complete -A hostname rsh telnet rlogin ftp ping xping host traceroute nslookup
> ...
> complete -u su

Two builtins `complete' and `compgen' with almost the same options,
functions starting with underscore, -[PS] options, COMPREPLY, arrays
holding names of stopped jobs and functions, etc.

`compgen' is lightly different from what was our `compgen', it
obviously just outputs the possible matches. But then -- the name.

Are we being monitored? ;-)

Unfortunately I couldn't any more info...

Bye
 Sven


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