Comments for bash programmable completion

07 Jan 2002 08:57 adamspiers

Re: Or you could just use zsh.

> > After all, zsh is better than bash in
> > every single regard.
> >
> > Seriously though, it's unfortunate
> > that we're reinventing all this
> > mechanism for each shell that has
> > programmable completion. The
> > bash-completion folks would like better
> > CVS completion, for example, but the zsh
> > folks have already put lots of work into
> > really excellent CVS completion.
> >
> > Perhaps some sort of shell-independent
> > completion layer, so that we could share
> > this substantial workload? Then maybe
> > application authors could include
> > completion files with their software.
> > Right now they're unlikely to do so,
> > since they'd have to target every shell
> > independently...

It's a nice thought; in fact Felix Rosencrantz has already been doing some experiments on zsh-workers in writing higher-level completion descriptions in XML which gets translated to zsh completion code via XSLT. Have a look at:


http://www.geocities.com/f_rosencrantz/xml_completion.htm (http://www.geocities.com/f_rosencrantz/xml_completion.htm)


http://qwer.org/zshxml (http://qwer.org/zshxml)

> The only problem I have with zsh completion is that it's
> illegible to me (and I say that as a seasoned Perl hacker).

I'm also a seasoned Perl hacker, and while I agree that some bits of the internal code can look like a rat dropping core, there's nothing hugely scary about the API provided for writing your own completions. In fact, it's very pleasant to work with. Look at the _ssh file in Completion/Unix/Command for instance; it's extremely legible. Yes, there's a learning curve there, but it's all very well documented.

> So, while I agree that zsh is a great
> shell (especially in the realm of
> completion), I'd disagree that it's
> better in every single regard.

I'm very curious to hear what advantages you think bash has over zsh (so that I can hack zsh to negate them ;-)

20 Dec 2001 21:18 ianmacd

Re: why bash?

>
> I think most people just want a usable
> completion. And your script does not
> even work on bash 2.05, and tcsh has had
> completion for years, and the tarball
> comes with a large set of completions so
> that most users don't need to edit
> anything special or download
> "extra" stuff to get usable
> completion.


It does work on bash 2.05 if you apply the patch to bash that I include to obtain group completion. If you want to use a stock bash, just comment out the few lines that have {complete,compgen} -g in them.

Similarly, with just a couple of changes, everything works fine on bash 2.04, too. Just comment out the complete -o lines.

It's irrelevant that tcsh has had programmable completion for longer than bash. Many people prefer bash to tcsh and would like programmable completion within their familiar environment.

20 Dec 2001 20:59 timecop

Re: why bash?

> With tcsh, you can't bind shell functions to commands. Even if you could, many people would rather write their shell functions in Bourne syntax.


I think most people just want a usable completion. And your script does not even work on bash 2.05, and tcsh has had completion for years, and the tarball comes with a large set of completions so that most users don't need to edit anything special or download "extra" stuff to get usable completion.

20 Dec 2001 20:52 ianmacd

Re: Or you could just use zsh.

> After all, zsh is better than bash in
> every single regard.
>
> Seriously though, it's unfortunate
> that we're reinventing all this
> mechanism for each shell that has
> programmable completion. The
> bash-completion folks would like better
> CVS completion, for example, but the zsh
> folks have already put lots of work into
> really excellent CVS completion.
>
> Perhaps some sort of shell-independent
> completion layer, so that we could share
> this substantial workload? Then maybe
> application authors could include
> completion files with their software.
> Right now they're unlikely to do so,
> since they'd have to target every shell
> independently...


The only problem I have with zsh completion is that it's illegible to me (and I say that as a seasoned Perl hacker).

So, while I agree that zsh is a great shell (especially in the realm of completion), I'd disagree that it's better in every single regard.

20 Dec 2001 20:48 ianmacd

Re: why bash?

> > Imagine typing ssh [Tab] and being
> able to complete on hosts
> > from your ~/.ssh/known_hosts
> files. Or typing man 3 str[Tab]
> > and getting a list of all string
> handling functions in the UNIX
> > manual. mount system:[Tab] would
> complete on all exported
> > file-systems from the host called
> system, while make [Tab]
> > would complete on all targets in
> Makefile.
>
> Imagine doing all this years ago with
> tcsh, then think, why would I need bash
> at all?


With tcsh, you can't bind shell functions to commands. Even if you could, many people would rather write their shell functions in Bourne syntax.

Each to his own.

20 Dec 2001 20:34 timecop

why bash?
> Imagine typing ssh [Tab] and being able to complete on hosts
> from your ~/.ssh/known_hosts files. Or typing man 3 str[Tab]
> and getting a list of all string handling functions in the UNIX
> manual. mount system:[Tab] would complete on all exported
> file-systems from the host called system, while make [Tab]
> would complete on all targets in Makefile.

Imagine doing all this years ago with tcsh, then think, why would I need bash at all?

01 Dec 2001 21:05 egnor

Or you could just use zsh.
After all, zsh is better than bash in every single regard.

Seriously though, it's unfortunate that we're reinventing all this mechanism for each shell that has programmable completion. The bash-completion folks would like better CVS completion, for example, but the zsh folks have already put lots of work into really excellent CVS completion.

Perhaps some sort of shell-independent completion layer, so that we could share this substantial workload? Then maybe application authors could include completion files with their software. Right now they're unlikely to do so, since they'd have to target every shell independently...

Screenshot

Project Spotlight

ReciJournal

An open, cross-platform journaling program.

Screenshot

Project Spotlight

Veusz

A scientific plotting package.