Re: Great hack, but ...
> It looks like ksh93-style extended
> globs don't work. What does shopt
> extglob say? If it's turned off, turn it
> on with shopt -s extglob.
> bash_completion should be turning it on,
> though. Have you edited the
> bash_completion file at all?
extglob is turned on and I have not edited /etc/bashrc nor /etc/bash_completion at all.
BTW, since my main box has a memory error, I'm trying your bash completion on my skipjack (RH 7.3 beta) laptop. Unfortunately, I get the same errors.
> ~/.bashrc on a standard RHL 7.2 box
> should contain the following:
> # Source global definitions
> if [ -f /etc/bashrc ]; then
> . /etc/bashrc
> so it should be getting sourced. Are
> you sure that ~/.bashrc is even getting
The standard ~/.bashrc has been long gone ;-) I didn't explain myself well enough. I checked the bash manpage and couldn't find a reference to /etc/bashrc, so I though perhaps there was some RH-specific mechanism whereby /etc/bashrc was sourced. I have no problem adding the line you suggest --- in fact I already did it --- I just wanted to know if there was something I was overlooking.
I'd be happy to help you debug this. Let me know if I can help. If so, We should probably take it offline. I can be reached at vladimir at acm dot org.
> 1. I get lots of error messages from
> function names beginning with
> "_" when I execute some Bourne
> shell programs. For instance, when just
> invoke `sh' I get:
> $ sh
> sh: _cd: line 3: syntax error in
> conditional expression
> sh: _cd: line 3: syntax error near
> unexpected token `?(.'
> sh: _cd: line 3: ` if [ -z
> "$CDPATH" ] || [[
> "$cur" == ?(.)?(.)/* ]];
> sh: error importing function
> definition for `_cd'
It looks like ksh93-style extended globs don't work. What does shopt extglob say? If it's turned off, turn it on with shopt -s extglob. bash_completion should be turning it on, though. Have you edited the bash_completion file at all?
> 2. /etc/bashrc doesn't seem to be
> executed automatically on my Red Hat 7.2
> system. It's easy enough to add
> "source /etc/bashrc" to
> ~/.bashrc, but is this the way it's
> supposed to be?
~/.bashrc on a standard RHL 7.2 box should contain the following:
# Source global definitions
if [ -f /etc/bashrc ]; then
so it should be getting sourced. Are you sure that ~/.bashrc is even getting sourced?
Great hack, but ...
I seem to have two problems:
1. I get lots of error messages from function names beginning with "_" when I execute some Bourne shell programs. For instance, when just invoke `sh' I get:
sh: _cd: line 3: syntax error in conditional expression
sh: _cd: line 3: syntax error near unexpected token `?(.'
sh: _cd: line 3: ` if [ -z "$CDPATH" ] || [[ "$cur" == ?(.)?(.)/* ]]; then'
sh: error importing function definition for `_cd'
plus 9 other sets of errors like these. Is there something wrong with my setup, or have I set something that I shouldn't, or is this just something I have to live with?
2. /etc/bashrc doesn't seem to be executed automatically on my Red Hat 7.2 system. It's easy enough to add "source /etc/bashrc" to ~/.bashrc, but is this the way it's supposed to be?
P.S. I would be bummed if I can't get at least #1 fixed because I really like this completion. Neat hack!
Re: Or you could just use zsh. or both
bla mine is better, no mine.... no no no
MINE, or all of them
all shells have their advantages. geez.
why would bash be so popular if it sucks so much you all say.
Very nice package. It makes tab completion in bash much more useful. I would recommend it to everyone. One thing I would like to see in the future is optional file name colorization as in ls --color=...
Another gift from Linux Heaven, if there is such a place. One word describes this addition to bash, 'logical'. If you type:
why in the name of Tux would you expect a list of files? To me it seems like more of a bug fix in bash than a new feature, but either way, bash users are all the more satisfied because of it.
Re: Or you could just use zsh.
> The only problem I have with zsh completion
> is that it's illegible to me (and I say that as
> a seasoned Perl hacker).
At a basic level, zsh completions are no harder to write than for bash. Bash's system was clearly inspired by zsh (the variables have different names and instead of the compadd builtin matches are put in an array). It'd be very easy to write a wrapper so that zsh could use completions written for bash. Once you learn more about the zsh system, functions can be written much more quickly and succinctly than for bash because there are many helper functions which do much of the work for you.
I will concede that some of the prewritten zsh completions are not entirely easy to understand but only because the system is so much more powerful. It's ability to display descriptions with matches makes it as valuable for providing hints and help as for saving you typing by completing words. And with so many functions already written, you shouldn't even need to worry much about writing your own functions.
Bash's lack of loadable functions is probably going to make it fairly slow to load all these completions before long.
Well I think it is pretty awesome....
I enjoy using bash and thought it was awesome to add these features without having to learn another shell. I have have been using bash for a quite a while and find it very useful to be able to have all of the extra tab completion.
Keep up the good work.
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?
Imagine an internet without annoying trolls like yourself. If you like tcsh then use it and STFU. Why would you even bother posting that?
Integrated in the bash package of debian testing
Just to let you know that it's now included in the bash package of the debian testing distro.
You have to uncomment stuff in /etc/bash* to activate it.
An open, cross-platform journaling program.
A scientific plotting package.