Example of broken completion (mixing env variable and path)
WIth a traditional bash, it often happens that I type :
cd $PWD/ [and press TAB]
so that it completes into
and then I quit the shell.
Now the directory where I left the shell is in the history.
When starting a new shell, a Ctrl-R cd (or even up arrow)
brings me back to the dir I was working before. I can open
many terminals and jump right into the without editing any
cdpath or the like. This is standard bash behavior.
With bash_completion activated,
cd $PWD/ [TAB]
"fails" (it flashed and does nothing),
so the happy behaviour used for years is broken.
Any idea how to modify bash_completion so that this
appreciated behaviour still works ? Thanks.
Please allow user to revert to standard bash completion at any time (a must-have).
Currently, the arguably interesting features of
bash_completion actually interfere with some completion
patterns that bash had for years, (for example completing
a path stopping at cursor, when the cursor is in the middle
of the line, but there are other cases in previous
Generally, until it can be proven that a change makes the
situation better at all times without any (even minor)
downside, the change should be reversible and never
So, any user should be able to turn it off. The simplest
idea is to unset the involved environment variables.
But BASH_COMPLETION and BASH_COMPLETION_DIR
are declared as read-only. Why ?
This prevents a particular user to turn it off... :-(
On a system with many users, there's currently no other
choice than to ask the administrator to remove the
package for all users (or make it not activated by default,
which is not what we need either).
Is it currently possible for a user to revert to standard
bash completion ? If not, please consider changing
something in the package (even something as simple as
checking for some ~/.bash_completionrc for a hint should
The risk is that, on any big site, new users don't even
know what comes from your package or even that it
exists, but people that used normal bash completion
completion in ways *you* don't use will dislike the package
(becauses it causes less efficient work) and have it
removed for all users.
A last suggestion : use savannah.nongnu.org or
sourceforge.net to have real forums. Freshmeat comments
aren't structured enough so that contributors can make a
good job of checking if a request was already issued
before. User feedback quality depends on this.
Variable-name completion bug
When I tab out an environment variable during a cd, the $(dollar sign) sign is escaped so although the tab completion happens the cd doesn't work. e.g
cd $JA[hit tab] and this lines becomes
cd \$JAVA_HOME[hit enter] and I get
-bash: cd: $JAVA_HOME: No such file or directory
If I comment out the bash-completion line in .bashrc this doesn't happen - the tab completion works correctly.
I started this thread on the gentoo forums
and mhodak has tried the latest version available 20040704-r1, and reports the bug is still there.
non local completion
Thanks for a great complement to the bash system. All of the Unix guys here love your bash extenstion.
I do have one point of extreme fustration though and I was hoping that you can help. It is probably a configuration issue or user error but here it is:
Let's say I am in the .../development directory
oxbow.matt 11 $ pwd
oxbow.matt 12 $ ls
includes/ images/ index.php
now I want to go into my includes directory:
oxbow.matt 13 $ cd inc<tab><cr>
this will complete as:
oxbow.matt 13 $ cd include
and then take me to /usr/local/include instead of the desired .../development/includes directory.
Is there any way to get the file name completion to fully complete on items in the currecnt directory and then if there are no items in the current dir that match then search CDPATH or whereever it looks to complete filenames? The completion should give preference to locally available items (to me somewhat obviously) instead of items off in far flung reaches of the system.
Please help me with this one, it bites me all day long every day.
Re: Thanks but please remove The Feature
> % Thanks for the bash complete but I
> % that the ``Forced ending'' of a path
> % when there ARE more possible subdirs to be a VERY annoying Feature.
> % Please Sir: stop ending EVERY subdir with a space.
> % If it can't be done then I must
> % uninstall. :(
> The limitation you describe is not
> something that the bash completion does;
> it's a limiation of bash, itself.
Ian, Please let me say that I can only think of two words to your reply and I mean them tongue in cheek: "prove it!" :)
What I mean is (I haven't studied the code yet) I think $IFS is being used an extra time. Hope this helps.
> Thanks for the bash complete but I find
> that the ``Forced ending'' of a path
> when there ARE more possible subdirs to
> be a VERY annoying Feature.
> Please Sir: stop ending EVERY subdir
> with a space.
> If it can't be done then I must
> uninstall. :(
The limitation you describe is not something that the bash completion does; it's a limiation of bash, itself.
Thanks but please remove The Feature
Thanks for the bash complete but I find that the ``Forced ending'' of a path when there ARE more possible subdirs to be a VERY annoying Feature.
Please Sir: stop ending EVERY subdir with a space.
If it can't be done then I must uninstall. :(
if curpath is dir, add '/'
else if non-dir name, wait (no output)
Re: Wishlist: GNU info
> I usually use "info" rather
> than "man". It would
> be great to have completion for that as
> well. For
> starters, why not just let an info
> complete with the same arguments as the
> corresponding man?
> Anyway, thanks for the nice code :-)
The latest version has rudimentary info completion.
> well. For starters, why not just let an info
> command complete with the same
> arguments as the corresponding man?
I wrote a completion function for info based on man and emailed it to Ian a few weeks ago. Hopefully he'll put it in the next release.
Wishlist: GNU info
I usually use "info" rather than "man". It would
be great to have completion for that as well. For
starters, why not just let an info command
complete with the same arguments as the
Anyway, thanks for the nice code :-)
A job dispatching server.
A lightweight subset of Libxmp.