Branches
Comments
[»]
svn mod: listing targets of imported build files
by Richard - Jan 26th 2007 09:24:01
in bash_completion _ant()
change:
local cur prev buildfile i
to:
local cur prev buildfile imports i f
add:
imports=(
$( awk -F'"' '/<import file="/ {print $2}'
\
$buildfile )
$( awk -F"'" "/<target name='/
"'{print $2}' \
$buildfile )
)
for f in ${imports[@]}; do
if [[ -e $f ]]; then
COMPREPLY=( ${COMPREPLY[@]} \
$( awk -F'"' '/<target name="/ {print
$2}' \
$f | grep "^$cur" | grep -v '^-' )
$( awk -F"'" "/<target name='/
"'{print $2}' \
$f | grep "^$cur" | grep -v '^-' )
$( awk -F'"' '/<target [^n]/ {if ($1 ~
/name=/) { print $2 } else if ($3 ~ /name=/) {print $4} else if ($5 ~
/name=/) {print $6}}' \
$f | grep "^$cur" | grep -v '^-' )
)
fi
done
change:
have complete-ant-cmd.pl && \
complete -C complete-ant-cmd.pl -F _ant $filenames ant || \
complete -F _ant $filenames ant
}
to:
have complete-ant-cmd.pl && \
complete -C complete-ant-cmd.pl -F _ant $filenames ant || \
complete -F _ant ant
}
[reply]
[top]
[»]
cd mod allowing ignore directories
by Richard - Jan 26th 2007 09:21:38
Allows one not to have to deal with '.svn' and
'CVS' directories.
in .bashrc
cdignore=( CVS .svn )
in bash_completion _cd() add:
if [ -z "${CDPATH:-}" ] || [[ "$cur" == ?(.)?(.)/*
]]; then
_filedir -d
if [[ -n "$cdignore" ]]; then
k=0
a=()
for f in ${COMPREPLY[@]}; do
i=0
for v in ${cdignore[@]}; do
if [[ "$f" == "$v"
]]; then
i=1
fi
done
if [[ $i -eq 0 ]]; then
a[k++]=$f
fi
done
COMPREPLY=( ${a[@]} )
fi
return 0
fi
[reply]
[top]
[»]
xine completion
by Mind Booster Noori - Jun 23rd 2006 04:21:54
Hi there,
I did a small file for xine completion, that can be downloaded here. If
you're interested, it would be cool if you could put that file on the
contrib directory of bash-completion...
Best regards.
[reply]
[top]
[»]
Very useful idea, but am experiencing too many difficulties
by Allen Halsey - Jan 4th 2006 14:31:33
First off, I want to thank the author for developing this extension to
bash. When it works, it really makes working at the command line much more
pleasant and enhances productivity.
I am using bash 3.00.16 and bash-completion version 20050721.
It mostly works for me, but I am encountered some difficulties and decided
to uninstall it.
1. The yum completion didn't know of the new 'localinstall' command token.
To get past this I manually typed 'localinstall'. But then when I pressed
TAB to do a filename completion on the .rpm file I was trying to install,
the completion choices where still offering yum's sub-command tokens
instead of filename completions. How do I inform bash-completion about the
new 'localinstall' token?
2. The Yum situation became worse when I tried to use it with sudo.
3. Glob expansion when pressing TAB stopped working. That is, I used to be
able to type:
$ ls *.c<TAB>
and this would change to:
$ ls myfile.c
This useful behavior returned when I uninstalled bash-completion.
4. It seems under-documented. Documentation at website didn't help me
figure out where the yum completions where coming from. I don't know if
this is a yum bug or a bash-completion bug. Is there a man page for
it?
5. I would urge the author to move the project to a site that allowed
better collaboration and bug tracking.
Allen Halsey
[reply]
[top]
[»]
apachectl
by jesse wolfe - Aug 4th 2005 13:25:47
i found that i've been using the apachectl command pretty often, and it's
possible commands are real simple: start, stop, restart, etc
well, this is perfect for complete -W , but i'm lazy, so i wrote a regexp
to extract the command list from the help screen (using sed, it could
probably be done entirely in bash, but i think comfortably in pipes and
filters rather than bash-syntax functions)
complete -W "`apachectl help | sed -n 's/^\([a-zA-Z1-9_]\{1,\}\)[
].*/\1/p'`" apachectl
[reply]
[top]
[»]
BASH_COMPLETION is readonly, except in functions?
by GaelicWizard - Apr 25th 2005 15:25:36
At the top of the script, whether or not it is being sourced
inside a function is checked. If so, then set the variables. If
not, then set them to be read-only.
Obviously, the better behaviour would be to make them
readonly all the time, but this is not implemented because
`declare -r' would then make those variables local to the
function. Here is a fix:
Use the `readonly' builtin. In fact, using this can mean that
the check for "$FUNCNAME" can be removed completely.
Simply:
BASH_COMPLETION=blah
readonly BASH_COMPLETION
All done. :-)
Unless I've missed something, this would be a welcome
change in the next release. (I do source bash_completion
from a function.)
JP
[reply]
[top]
[»]
Re: BASH_COMPLETION is readonly, except in functions?
by Ian Macdonald - Jul 7th 2005 17:13:45
> At the top of the script, whether or not
> it is being sourced
> inside a function is checked. If so,
> then set the variables. If
> not, then set them to be read-only.
>
> Obviously, the better behaviour would be
> to make them
> readonly all the time, but this is not
> implemented because
> `declare -r' would then make those
> variables local to the
> function. Here is a fix:
>
> Use the `readonly' builtin. In fact,
> using this can mean that
> the check for "$FUNCNAME" can
> be removed completely.
> Simply:
>
> BASH_COMPLETION=blah
> readonly BASH_COMPLETION
>
> All done. :-)
>
> Unless I've missed something, this would
> be a welcome
> change in the next release. (I do source
> bash_completion
> from a function.)
>
> JP
Unfortunately, this causes an error to be printed if
'BASH_COMPLETION=blah' is executed for a second time. Redirection doesn't
work on assignment, so this can't be silenced, except by using 'declare',
which makes the variable local to the function.
[reply]
[top]
[»]
Subversion completion
by R.Ramkumar - Mar 28th 2005 20:21:03
There is a completion script at
http://worksintheory.org/files/misc/bash_completion_svn which is much
better than the one currently shipped with contrib. May be that could be
included in the next release.
[reply]
[top]
[»]
Re: Subversion completion
by Ian Macdonald - Jul 11th 2005 17:34:56
> There is a completion script at
> http://worksintheory.org/files/misc/bash_completion_svn
> which is much better than the one
> currently shipped with contrib. May be
> that could be included in the next
> release.
Who is the copyright holder of this file? I can't start to package it
without his agreement, as the file itself contains no licensing
information.
[reply]
[top]
[»]
autocompletion of mutt aliases?
by jamespo - Mar 11th 2005 09:49:20
great project - there is one feature I'd like
the ability to autocomplete based on mutt's ~/.mutt.aliases file.
ie mutt [tab][tab]
gives a list of mutt aliases for recipients
I have tried to code this, but failed,
[reply]
[top]
[»]
Suggestion
by Virginio GL - Oct 22nd 2004 03:03:31
I think that implement bash completion for emerge
utility of Gentoo distibution is a good idea.
Emerge is similar to apt-get in Debian.
Thanks.
[reply]
[top]
[»]
Example of broken completion (mixing env variable and path)
by Stéphane Gourichon - Oct 4th 2004 08:07:38
WIth a traditional bash, it often happens that I type :
cd $PWD/ [and press TAB]
so that it completes into
cd /my/current/path
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.
Regards,
--
"J'y gagne, répondit le renard, à cause de la couleur du blé."
[reply]
[top]
[»]
Re: Example of broken completion (mixing env variable and path)
by Michael - Dec 22nd 2006 03:46:57
Having experienced the same problem, I hacked the _cd function in bash
completion:
cd()
{
local IFS=$'\t\n' cur=${COMP_WORDS[COMP_CWORD]} i j k
# Hack start
if [[ "$cur" == ?(\\)\$* ]]; then
local v cur1=${cur#?(\\)$}
# "set -o posix" makes "set" only show variables, not
functions
local envs=`set -o posix; for v in $(set | /bin/sed
's/^\(.*\)=.*/\1/g' | /bin/grep "^$cur1"); do if [ -d "$(eval echo \\$$v)"
]; then eval echo \\$$v; fi; done`
COMPREPLY=($( compgen -W "$envs" ));
if (( ${#COMPREPLY[*]} == 1 )); then
return 0
fi
fi
# Hack end
# try to allow variable completion
if [[ "$cur" == ?(\\)\$* ]]; then
COMPREPLY=( $( compgen -v -P '$' -- "${cur#?(\\)$}" )
)
return 0
fi
(... rest as before)
While this certainly isn't perfect, it will complete unique variables. I
know the code is horrible, and anyone with more insight in using "compgen",
"sed" etc. are hereby encouraged to make a better solution.
> WIth a traditional bash, it often
> happens that I type :
> cd $PWD/ [and press TAB]
> so that it completes into
> cd /my/current/path
> 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.
>
> Regards,
[reply]
[top]
[»]
Re: Example of broken completion (mixing env variable and path)
by Michael - Dec 22nd 2006 23:24:18
Working a bit more on it, the follwoing code does the same more
elegantly:
_cd()
{
local IFS=$'\t\n' cur=${COMP_WORDS[COMP_CWORD]} i j k
# Start of modifications
if [[ "$cur" == ?(\\)\$* ]]; then
local v vars=$(compgen -v -X !${cur#?(\\)$}*)
COMPREPLY=(`for v in $vars; do if [ -d "$(eval echo \\$$v)" ];
then eval echo \\$$v; fi; done`)
if (( ${#COMPREPLY[*]} == 1 )); then
return 0
fi
# No single completion. Then just list the variables being
directories.
COMPREPLY=(`for v in $vars; do if [ -d "$(eval echo \\$$v)" ];
then echo \\$$v; fi; done`);
return 0
fi
# old stuff removed
# # try to allow variable completion
# if [[ "$cur" == ?(\\)\$* ]]; then
# COMPREPLY=( $( compgen -v -P '$' -- "${cur#?(\\)$}" ) )
# return 0
# fi
#
# (unchanged from here)
[reply]
[top]
[»]
Re: Example of broken completion (mixing env variable and path)
by Michael - Dec 30th 2006 01:32:26
A bit more work on it to get rid of the redunant loop yields:
>_cd()
>{
> local IFS=$'\t\n' cur=${COMP_WORDS[COMP_CWORD]} i j k
>
># (start of changes)
> if [[ "$cur" == ?(\\)\$* ]]; then
> local v vars
> vars=($(for v in $(compgen -v -X !${cur#?(\\)$}*); do if
[ -d "$(eval echo \$$v)" ]; then echo \$$v; fi; done))
> if (( ${#vars[*]} == 1 )); then
> # A single completion. Expand it.
> COMPREPLY=($(eval echo $vars))
> return 0
> fi
> # No single completion. Then just list the variables
being directories.
> COMPREPLY=(${vars[*]});
> return 0
> fi
>
># old stuff ...
># # try to allow variable completion
># if [[ "$cur" == ?(\\)\$* ]]; then
># COMPREPLY=( $( compgen -v -P '$' -- "${cur#?(\\)$}" )
)
># return 0
># fi
># (unchanged from here)
[reply]
[top]
[»]
Please allow user to revert to standard bash completion at any time (a must-have).
by Stéphane Gourichon - Oct 4th 2004 07:59:13
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
comments).
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
imposed.
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
be fine).
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.
Regards,
--
"J'y gagne, répondit le renard, à cause de la couleur du blé."
[reply]
[top]
[»]
Re: Please allow user to revert to standard bash completion at any time (a must-have).
by Ian Macdonald - Oct 8th 2004 17:20:08
> 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... :-(
These are set read-only, because it's bad to change them once they've been
set. They are used later on and it's important that the value doesn't
change. They can be set before the bash_completion script is run, however,
and the original value will be honoured.
> 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 ?
Yes, just run 'complete -r' and all completions will be removed, leaving
just the default. However, I agree that this isn't the most useful way of
achieving this, so I will consider the implementation of a better
mechanism.
> 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.
Well, e-mail works well, too. I agree that this forum isn't very efficient
or convenient, so just e-mail me your comments instead. It would be nice to
have a real mailing list, though. I'll consider setting one up.
[reply]
[top]
[»]
Thank you (Re: Please allow user to revert to standard bash completion at any time (a must-have).)
by Stéphane Gourichon - Oct 9th 2004 01:13:47
> Yes, just run 'complete -r' and all
> completions will be removed, leaving
> just the default. However, I agree that
> this isn't the most useful way of
> achieving this, so I will consider the
> implementation of a better mechanism.
Thank you. A quick test showed that
indeed the "broken" behaviors do work again. This is
enough for my purpose and some
investigation will allow to selectively remove some of the
completions but not all.
Thank you for this constructive reply.
May I suggest to include both explanations (about the need
that the env variables do not change, and a way to turn the
feature off -- although the latter is actually a bash feature) in
the package documentation and on the project web page ?
Regards,
--
"J'y gagne, répondit le renard, à cause de la couleur du blé."
[reply]
[top]
[»]
Variable-name completion bug
by colin - Aug 9th 2004 02:28:01
Hi Ian,
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'm using
bash-2.05b-r9
bash-completion 20040526
I started this thread on the gentoo forums
http://forums.gentoo.org/viewtopic.php?p=1419973#1419973
and mhodak has tried the latest version available 20040704-r1, and reports
the bug is still there.
Cheers mate.
Colin.
[reply]
[top]
[»]
Re: Variable-name completion bug
by Ian Macdonald - Jul 11th 2005 17:39:31
> 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'm using
> bash-2.05b-r9
> bash-completion 20040526
>
> I started this thread on the gentoo
> forums
> http://forums.gentoo.org/viewtopic.php?p=1419973#1419973
>
> and mhodak has tried the latest version
> available 20040704-r1, and reports the
> bug is still there.
To get the behaviour you desire. you have to change this line:
complete -v -F _cd $nospace $filenames cd
Remove '$filenames', which will cause bash to no longer treat the
variable name as a filename, so it won't escape it.
Unfortunately, it will now also no longer append a slash to a path.
These are the kinds of trade-offs that bash's programmable completion
implementation requires, I'm afraid.
[reply]
[top]
[»]
non local completion
by Matt M - Jul 19th 2004 08:11:15
Ian,
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
/tmp/development
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.
Thanks
Matt
[reply]
[top]
[»]
Thanks but please remove The Feature
by B - Jul 4th 2004 18:50:30
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. :(
Thanks again.
pseudo-code:
if curpath is dir, add '/'
else if non-dir name, wait (no output)
.
--
I ought to obey God before Man.
[reply]
[top]
[»]
Re: Thanks but please remove The Feature
by Ian Macdonald - Jul 10th 2004 14:42:30
> 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.
[reply]
[top]
[»]
Re: Thanks but please remove The Feature
by B - Jul 12th 2004 13:20:50
>
> % 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.
>
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!" :)
LOL.
What I mean is (I haven't studied the code yet) I think $IFS is being used
an extra time. Hope this helps.
--
I ought to obey God before Man.
[reply]
[top]
[»]
Re: Thanks but please remove The Feature
by Ian Macdonald - Jul 11th 2005 17:28:51
>
> % % 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!"
> :)
>
> LOL.
>
> What I mean is (I haven't studied the
> code yet) I think $IFS is being used an
> extra time. Hope this helps.
Please tell me which particular command is giving you this behaviour and
which version of bash you are using.
[reply]
[top]
[»]
Wishlist: GNU info
by Niels Vestergaard Jensen - Jan 31st 2004 14:11:29
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
corresponding man?
Anyway, thanks for the nice code :-)
[reply]
[top]
[»]
Re: Wishlist: GNU info
by FattMattP - Apr 22nd 2004 20:42:02
> 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 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.
[reply]
[top]
[»]
Re: Wishlist: GNU info
by Ian Macdonald - May 26th 2004 01:53:12
> 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
>
> corresponding man?
>
> Anyway, thanks for the nice code :-)
The latest version has rudimentary info completion.
[reply]
[top]
[»]
~ completion
by José Romildo Malaquias - Jan 2nd 2004 02:50:19
I have noticed that with the bash-completion package loadead, the
completion of "~" differs from the original bash completion, in
that it is replaced by what it means (the user home directory). I would
like to keep the original "~" character in the command line,
instead of replacing it with the actual directory it represents, when
running bash-completion. Is that possible? How?
Regards.
[reply]
[top]
[»]
Ant Completion
by Itamar Carvalho - Dec 26th 2003 16:44:13
The ant completion code presumes that the first XML parameter to the
"target" tag will be "name".
Some of my build.xml files don't have this order (if you use NetBeans to
edit the build.xml using the ant tools, the "name" will be the
last parameter).
Below a path that works for me (I know it's not as good as it could
be):
--- /tmp/bash_completion.old 2003-12-26 21:37:11.000000000 -0300
+++ /etc/bash_completion 2003-12-26 21:35:20.000000000 -0300
@@ -2768,6 +2768,8 @@
COMPREPLY=( $( awk -F'"' '/<target name="/
{print $2}' \
$buildfile | grep "^$cur" )
$( awk -F"'" "/<target
name='/ "'{print $2}' \
+ $buildfile | grep "^$cur" )
+ $( awk -F'"' '/<target [^n]/ {if ($1 ~
/name=/) { print $2 } else if ($3 ~ /name=/) {print $4} else if ($5 ~
/name=/) {print $6}}' \
$buildfile | grep "^$cur" ) )
fi
}
--
Itamar Carvalho
[reply]
[top]
[»]
Re: Ant Completion
by Ian Macdonald - Dec 31st 2003 17:06:12
> The ant completion code presumes that
> the first XML parameter to the
> "target" tag will be
> "name".
>
> Some of my build.xml files don't have
> this order (if you use NetBeans to edit
> the build.xml using the ant tools, the
> "name" will be the last
> parameter).
>
> Below a path that works for me (I know
> it's not as good as it could be):
>
> --- /tmp/bash_completion.old
> 2003-12-26 21:37:11.000000000 -0300
> +++ /etc/bash_completion
> 2003-12-26 21:35:20.000000000 -0300
> @@ -2768,6 +2768,8 @@
> COMPREPLY=( $( awk
> -F'"' '/<target name="/
> {print $2}' \
>
> $buildfile | grep "^$cur" )
> $( awk
> -F"'" "/<target
> name='/ "'{print $2}' \
> +
> $buildfile | grep "^$cur" )
> + $( awk
> -F'"' '/<target [^n]/ {if ($1 ~
> /name=/) { print $2 } else if ($3 ~
> /name=/) {print $4} else if ($5 ~
> /name=/) {print $6}}' \
>
> $buildfile | grep "^$cur" ) )
> fi
> }
>
Can you please send this to me directly as a unified diff?
Cheers,
Ian
[reply]
[top]
[»]
Wonderful... but...
by GaelicWizard - Oct 5th 2003 02:14:11
I LOVE bash_completion, but I think that it is growing
just a tad too big... and a little unmanageable.
Spesific gripes:
1) If $UNAME isn't tested explicitly for an OS that
doesn't return xyz then feature abc which worx, is not
completed upon. I'm not sure how this is fixable, its just
a comment. :-)
2) some of the functions and completions seem to be
slightly more complex than neccessary. What I mean is
that I don't see the need to redefine the builtin
completions if the builtin ones work.
3) It seems to be very linux spesific, although almost all
worx on freeBSD it checks vigorously for linux in
$UNAME.
Thanx, keep up the good work!
[reply]
[top]
[»]
Re: Wonderful... but...
by Ian Macdonald - Oct 7th 2003 00:12:10
> I LOVE bash_completion, but I think that
> it is growing
> just a tad too big... and a little
> unmanageable.
> Spesific gripes:
> 1) If $UNAME isn't tested explicitly for
> an OS that
> doesn't return xyz then feature abc
> which worx, is not
> completed upon. I'm not sure how this is
> fixable, its just
> a comment. :-)
> 2) some of the functions and completions
> seem to be
> slightly more complex than neccessary.
> What I mean is
> that I don't see the need to redefine
> the builtin
> completions if the builtin ones work.
> 3) It seems to be very linux spesific,
> although almost all
> worx on freeBSD it checks vigorously for
> linux in
> $UNAME.
>
> Thanx, keep up the good work!
I'll deal with your numbered comments in turn. First, though, I'll respond
to your remark that the project is becoming too big and unmanageable.
This is a fair comment. There is some inconsistency in coding style
throughout the file, which is the result of the fact that bash completion
these days is the work of many different people. As far as formatting is
concerned, a version of indent(1) for Bourne shell code would be great, but
doesn't exist.
I think I'm doing a reasonable job of managing the code in the file, but I
will agree that the file as a whole is unwieldy. It would definitely be
better if it could be split into multiple files, but I don't see a great
enough benefit to doing this until such time that bash supports loadable
functions.
Otherwise, there's some administrative gain, but the extra overhead of
parsing dozens and dozens of small files.
Now to your numbered comments:
1. $UNAME is there to ensure that certain commands that are known to work
differently on different platforms behave as expected when the completion
routine is written primarily for one or two specific operating systems.
If you know of specific instances of over-conservative code, where
programmable completion is excluded for a platform that you know it would
work with, please let me know about it and preferably send a patch.
2. A lot of the functions need to be more complex than you might at first
think. _cd() is a good example of this. Standard completion doesn't offer
you a lot of features, but in the case of _cd(), you get to complete on
directories defined in $CDPATH. If you don't use $CDPATH, this might seem
like overkill, but to other people, it's invaluable.
3. Please send me a list of commands for which there are completions that
currently default to doing nothing on FreeBSD, but which would work
absolutely fine if enabled. In other words, I'd like to know about cases
where the code for FreeBSD is identical to the Linux code.
[reply]
[top]
[»]
mac os x
by mgiorget - Jun 30th 2003 14:27:35
Hi all. i'm trying to get this magical bash_completion
feature working on my mac os x 10.2 (with no
success). i tryed to source directly from the file I
dowloaded from the bash homepage, and if I run it as
root it sources it but has some problems (like mount
<tab><tab> looks for /etc/fstab, which doesn't exist in
mac os), so i was wondering if you knew some
"sourceable" file suitable for mac os x.
thanks
george
(sorry for the previous reply I just didn't see the "add
comment" button...)
[reply]
[top]
[»]
Re: mac os x
by mgiorget - Jun 30th 2003 14:37:55
Well i've had a look at the code of bash_completion and
i've seen that Darwin is contemplated only in the
completion of the command "man". this is quite
disappointing for me :-(
do you know if anyone has started to work on bash
completion for darwin?
thanks
[reply]
[top]
[»]
Re: mac os x
by Ian Macdonald - Jul 1st 2003 02:43:12
> Hi all. i'm trying to get this magical
> bash_completion
> feature working on my mac os x 10.2
> (with no
> success). i tryed to source directly
> from the file I
> dowloaded from the bash homepage, and if
> I run it as
> root it sources it but has some problems
> (like mount
> <tab><tab> looks for
> /etc/fstab, which doesn't exist in
> mac os), so i was wondering if you knew
> some
> "sourceable" file suitable for
> mac os x.
> thanks
> george
>
> (sorry for the previous reply I just
> didn't see the "add
> comment" button...)
There's a Fink
package that may be what you're looking for. As for the absence of
/etc/fstab, if you send me details of what the Mac's file-system table
looks like, I'll be happy to add support for it.
[reply]
[top]
[»]
Re: mac os x
by mgiorget - Jul 3rd 2003 07:28:08
The problem is that the differences may not be only
about the fstab file (well I'm kinda sure of that...).
As I can list the features needed for mac os x I'll send
them to you ok?
Late,
Marco
[reply]
[top]
[»]
RE: cd in CDPATH does not add trailing slash...
by Berkeley S. D. Wolf - Jun 23rd 2003 23:25:58
Found the fix:
in _cd(), At line 2466, add a slash to the end of the line,
i.e. the line should look like:
COMPREPLY[$k]=${j#$i/}/
Voila.
[I will also note that bash_completion does some annoying things under
version < 2.05b, but that's not your problem. :-)]
--
--*greywolf;
/* greywolf at starwolf spot com */
[reply]
[top]
[»]
RE: cd in CDPATH does not add trailing slash...
by Berkeley S. D. Wolf - Jun 23rd 2003 23:32:04
> Found the fix:
>
> in _cd(), At line 2466, add a slash to
> the end of the line,
> i.e. the line should look like:
>
> COMPREPLY[$k]=${j#$i/}/
>
> Voila.
>
> [I will also note that bash_completion
> does some annoying things under version
> < 2.05b, but that's not your problem.
> :-)]
Bah.
Spoke too soon. That'll teach me.
--
--*greywolf;
/* greywolf at starwolf spot com */
[reply]
[top]
[»]
cd does not add trailing slashes if going thru CDPATH
by Berkeley S. D. Wolf - Jun 23rd 2003 21:46:52
I note that if I use cd and completion to complete dirs in CDPATH
somewhere, the trailing slash does not get added; how could this be
fixed?
--
--*greywolf;
/* greywolf at starwolf spot com */
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by Ian Macdonald - Jun 23rd 2003 23:16:25
> I note that if I use cd and completion
> to complete dirs in CDPATH somewhere,
> the trailing slash does not get added;
> how could this be fixed?
Please see the Troubleshooting section of the README that comes
with the tar file.
Basically, you need to upgrade your copy of bash.
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by Berkeley S. D. Wolf - Jun 23rd 2003 23:28:00
>
> % I note that if I use cd and
> completion
> % to complete dirs in CDPATH somewhere,
> % the trailing slash does not get
> added;
> % how could this be fixed?
>
>
>
> Please see the Troubleshooting section
> of the README that comes with the tar
> file.
>
> Basically, you need to upgrade your copy
> of bash.
I'm running 2.05b; I'm behind already?
--
--*greywolf;
/* greywolf at starwolf spot com */
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by Ian Macdonald - Oct 7th 2003 00:00:41
> I'm running 2.05b; I'm behind already?
You need to install the official patches to 2.05b. That will fix the lack
of trailing slash issue.
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by n - Nov 14th 2003 19:14:19
>
> % I'm running 2.05b; I'm behind
> already?
>
>
> You need to install the official patches
> to 2.05b. That will fix the lack of
> trailing slash issue.
I'm not sure why, but for some reason when I try and compile code with my
$CDPATH variables set, I often get errors where it can't 'cd' to the
correct directory, and bails saying that dir dosen't exist. This is the
correct response:
user@host> make
cd lib/ && make lib
make[1]: Entering directory `/home/jidar/src/proftpd-1.2.9/lib'
and with CDPATH and bash_completion loaded..
user@host> . /etc/bash_completion
user@host> export CDPATH=/var/www/htdocs
user@host> make
cd lib/ && make lib
/bin/sh: line 1: cd: lib/: No such file or directory
I just compiled my own version of bash, and applied all 7 patches.
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by n - Nov 14th 2003 19:40:08
>
> %
> % % I'm running 2.05b; I'm behind
> % already?
> %
> %
> % You need to install the official
> patches
> % to 2.05b. That will fix the lack of
> % trailing slash issue.
>
>
>
> I'm not sure why, but for some reason
> when I try and compile code with my
> $CDPATH variables set, I often get
> errors where it can't 'cd' to the
> correct directory, and bails saying that
> dir dosen't exist. This is the correct
> response:
>
> user@host> make
> cd lib/ && make lib
> make[1]: Entering directory
> `/home/jidar/src/proftpd-1.2.9/lib'
>
> and with CDPATH and bash_completion
> loaded..
> user@host> . /etc/bash_completion
> user@host> export
> CDPATH=/var/www/htdocs
> user@host> make
> cd lib/ && make lib
> /bin/sh: line 1: cd: lib/: No such file
> or directory
>
> I just compiled my own version of bash,
> and applied all 7 patches.
>
I think a simple fix to this might be,
alias make='unset CDPATH && make && . ~/.bash_profile'
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by Ian Macdonald - Nov 20th 2003 19:38:41
>
> %
> % %
> % % % I'm running 2.05b; I'm behind
> % % already?
> % %
> % %
> % % You need to install the official
> % patches
> % % to 2.05b. That will fix the lack of
> % % trailing slash issue.
> %
> %
> %
> % I'm not sure why, but for some reason
> % when I try and compile code with my
> % $CDPATH variables set, I often get
> % errors where it can't 'cd' to the
> % correct directory, and bails saying
> that
> % dir dosen't exist. This is the
> correct
> % response:
> %
> % user@host> make
> % cd lib/ && make lib
> % make[1]: Entering directory
> % `/home/jidar/src/proftpd-1.2.9/lib'
> %
> % and with CDPATH and bash_completion
> % loaded..
> % user@host> . /etc/bash_completion
> % user@host> export
> % CDPATH=/var/www/htdocs
> % user@host> make
> % cd lib/ && make lib
> % /bin/sh: line 1: cd: lib/: No such
> file
> % or directory
> %
> % I just compiled my own version of
> bash,
> % and applied all 7 patches.
> %
>
>
>
> I think a simple fix to this might be,
> alias make='unset CDPATH && make && .
> ~/.bash_profile'
This is very bizarre. Does 'complete -r cd' fix it, too? The completion
system should have nothing to do with a non-interactive command like make.
[reply]
[top]
[»]
Re: cd does not add trailing slashes if going thru CDPATH
by n - Dec 10th 2003 23:16:56
> This is very bizarre. Does 'complete -r
> cd' fix it, too? The completion system
> should have nothing to do with a
> non-interactive command like make.
>make
make all-recursive
make[1]: Entering directory `/home/jidar/src/gaim'
Making all in sounds
/bin/sh: line 1: cd: sounds: No such file or directory
>complete -r cd
>make
make all-recursive
make[1]: Entering directory `/home/jidar/src/gaim'
Making all in sounds
/bin/sh: line 1: cd: sounds: No such file or directory
short answer: no. Oddly, this has caused more problems and Its something I
comment out for general use. Although, its a feature I'd very much
like to use.
[reply]
[top]
[»]
Environment Variable Completion
by William Nagel - Apr 18th 2003 13:57:58
I love this project. Truly a great time/keystroke saver. I have had one
problem, though. Has anyone else found that environment variable
completion no longer works. The way I work, I find that I type a lot of
environment variable names, and the fact that Bash will no longer complete
them is very annoying.
[reply]
[top]
[»]
Re: Environment Variable Completion
by Ian Macdonald - Apr 18th 2003 17:53:42
> I love this project. Truly a great
> time/keystroke saver. I have had one
> problem, though. Has anyone else found
> that environment variable completion no
> longer works. The way I work, I find
> that I type a lot of environment
> variable names, and the fact that Bash
> will no longer complete them is very
> annoying.
Could you be more precise about exactly what you're attempting to do here?
[reply]
[top]
[»]
Folder completion for mutt or mailx?
by rog - Mar 31st 2003 12:33:24
Has anybody attempted folder completion for something like mutt?
> mutt -f =foo<tab>
would list
foobar foobaz food
mailx and many other MUAs use this "=folder" syntax from the
command line, so it would be useful for more than just mutt.
[reply]
[top]
[»]
badblocks
by ray - Feb 22nd 2003 05:31:19
i would like to complete the command badblocks
e.g. "badblocks -sv /dev/sda1"
because the E2fsprogs is a essential tool in every distribution
[reply]
[top]
[»]
"rm -r" completion
by ray - Feb 19th 2003 13:09:12
I would like to have a completion to the command "rm -r".
Only directories should be listed.
[reply]
[top]
[»]
Automatic change directory
by raopm - Feb 13th 2003 08:40:27
Would it be possible to add the automatic change directory feature to Bash
Completion?
If a directory called /usr/local/lib/foo exists and the command line
is:
$ /usr/local/lib/foo <return>
Then the action is to change to that directory instead of reporting that
"/usr/local/lib/foo" is a directory.
I've used this feature in other shells. Can this be done at the command
completion level or does it call for a more fundamental change in bash
itself?
[reply]
[top]
[»]
Re: Automatic change directory
by Ian Macdonald - Apr 18th 2003 18:37:42
> Would it be possible to add the
> automatic change directory feature to
> Bash Completion?
>
> If a directory called /usr/local/lib/foo
> exists and the command line is:
> $ /usr/local/lib/foo <return>
>
> Then the action is to change to that
> directory instead of reporting that
> "/usr/local/lib/foo" is a
> directory.
>
> I've used this feature in other shells.
> Can this be done at the command
> completion level or does it call for a
> more fundamental change in bash
> itself?
>
bash can't really do this, since it has no pre-execution hook for you to
tap into with code.
Nevertheless, to my surprise, I managed to botch together the following
hack:
trap '{ d=$_; [ -d "$d" ] && cd $d; unset d; }' ERR
This does what you want, but won't stop the attempt to run a directory
from displaying an error before changing to the directory.
[reply]
[top]
[»]
~/.bash_completion
by Tom Knight-Markiegi - Dec 8th 2002 06:24:03
Hi
In the documentation for bash_completion it says that to add local
completions they should go in ~/.bash_completion . What format should they
be in?
Cheers
[reply]
[top]
[»]
Re: ~/.bash_completion
by Ian Macdonald - Dec 9th 2002 11:27:44
> In the documentation for bash_completion
> it says that to add local completions
> they should go in ~/.bash_completion .
> What format should they be in?
They should be simple shell scripts. They will be sourced at the end of
/etc/bash_completion, so they need not contain a shebang line nor be
executable.
[reply]
[top]
[»]
rsync suport
by xayk - Nov 27th 2002 07:30:02
is rsync suport available and if not does anyone know when it will be?
regards
p.s.
i love bash completion :)
the only thing i wouldn't want it to support is password completion :))
[reply]
[top]
[»]
Re: rsync suport
by Ian Macdonald - Dec 9th 2002 11:29:13
> is rsync suport available and if not
> does anyone know when it will be?
>
> regards
> p.s.
> i love bash completion :)
> the only thing i wouldn't want it to
> support is password completion :))
Basic rsync support is in there already. Just try 'rsync --<Tab>'
and see what you get.
Thanks for your kind words.
[reply]
[top]
[»]
gdb
by Luciano Rocha - Oct 15th 2002 18:10:09
There's a "core *" missing in gdb:
@line 2595
+ COMPREPLY=( $( compgen -W "$( echo core.* $( ps axo
comm,pid |
BTW, it would be nice, when nothing matches, to have it revert to old
style. It's more annoying this way.
[reply]
[top]
[»]
Re: gdb
by Ian Macdonald - Oct 15th 2002 19:45:36
> There's a "core *" missing in
> gdb:
> @line 2595
> + COMPREPLY=( $( compgen
> -W "$( echo core.* $( ps axo
> comm,pid |
Why 'core.*' instead of 'core*'?
> BTW, it would be nice, when nothing
> matches, to have it revert to old style.
> It's more annoying this way.
You can get this by replacing:
[ $have ] && complete -F _gdb $filenames gdb
with:
[ $have ] && complete -F _gdb $default gdb
[reply]
[top]
[»]
Re: gdb
by Luciano Rocha - Oct 15th 2002 19:58:21
>
> % There's a "core *" missing
> Why 'core.*' instead of 'core*'?
core.* was a typo, the right thing to put is core*, of course.
> % BTW, it would be nice, when nothing
> % matches, to have it revert to old style.
> You can get this by replacing:
> [ $have ] && complete -F _gdb $filenames gdb
> with:
> [ $have ] && complete -F _gdb $default gdb
Thanks, but I wasn't thinking about gdb in particular, but in the whole
system. So that "tar cvzf something", bzip2, etc, could fallback to simple
filecompletion when nothing else matches.
[reply]
[top]
[»]
Re: gdb
by Ian Macdonald - Oct 15th 2002 20:06:18
> % % BTW, it would be nice, when nothing
> % % matches, to have it revert to old
> style.
> % You can get this by replacing:
> % [ $have ] && complete -F _gdb
> $filenames gdb
> % with:
> % [ $have ] && complete -F _gdb
> $default gdb
>
> Thanks, but I wasn't thinking about gdb
> in particular, but in the whole system.
> So that "tar cvzf something", bzip2,
> etc, could fallback to simple
> filecompletion when nothing else
> matches.
Unfortunately, there's no easy way of achieving this in bash.
[reply]
[top]
[»]
Re: gdb
by Luciano Rocha - Dec 3rd 2002 10:47:59
A change to the completion of gdb that i forgot to submit earlier:
change echo core* \ to compgen -f core* ;
[reply]
[top]
[»]
Re: gdb
by Ian Macdonald - Dec 9th 2002 11:33:49
> A change to the completion of gdb that i
> forgot to submit earlier:
> change echo core* \ to compgen -f core*
> ;
Thanks. This will be in the next release.
[reply]
[top]
[»]
Re: gdb
by Ian Macdonald - Dec 9th 2002 11:33:12
> There's a "core *" missing in
> gdb:
> @line 2595
> + COMPREPLY=( $( compgen
> -W "$( echo core.* $( ps axo
> comm,pid |
>
> BTW, it would be nice, when nothing
> matches, to have it revert to old style.
> It's more annoying this way.
You can't pass both '-o filenames' and '-o default' to the complete
built-in. bash's completion mechanism is inadequate in a number of ways and
this is just one of them.
[reply]
[top]
[»]
Problem with java -classpath completion
by Alexander Weber - Oct 9th 2002 07:53:37
Hi there,
in the 20021007 I'm getting the following error if I try to use
<TAB> after "java -classpath" :
bash: i++: command not found
Is there somthing wrong on my system, of is it a typo in
bash-completion?
Thx for the great proggi!
Alex :)
[reply]
[top]
[»]
Re: Problem with java -classpath completion
by Ian Macdonald - Oct 9th 2002 11:52:31
> in the 20021007 I'm getting the
> following error if I try to use
> <TAB> after "java
> -classpath" :
>
> bash: i++: command not found
>
> Is there somthing wrong on my system, of
> is it a typo in bash-completion?
Which version of bash is this? Hit C-x C-v to get the version number. The
'i++' in question is in a C-style 'for' loop. You could replace it with
'i=i+1' if your version of bash doesn't support the increment operator.
[reply]
[top]
[»]
Re: Problem with java -classpath completion
by Alexander Weber - Oct 10th 2002 07:28:40
Hi,
> Which version of bash is this? Hit C-x
> C-v to get the version number.
It's version:
GNU bash, version 2.05b.0(1)-release (i586-suse-linux)
> The 'i++'
> in question is in a C-style 'for' loop.
> You could replace it with 'i=i+1' if
> your version of bash doesn't support the
> increment operator.
After replacing the i++ in line 3077 with i=i+1 it results in the folowing
error:
bash: ((: i+1: expression recursion level exceeded (error token is
"i+1")
But after full removal of the statement it worked like expected.
Thx for support!
Alex :)
[reply]
[top]
[»]
Re: Problem with java -classpath completion
by Ian Macdonald - Oct 10th 2002 21:05:17
> % The 'i++'
> % in question is in a C-style 'for'
> loop.
> % You could replace it with 'i=i+1' if
> % your version of bash doesn't support
> the
> % increment operator.
>
>
> After replacing the i++ in line 3077
> with i=i+1 it results in the folowing
> error:
>
> bash: ((: i+1: expression recursion
> level exceeded (error token is "i+1")
Sorry. Make that i=i+1 into i=$((i+1)).
[reply]
[top]
[»]
Re: Problem with java -classpath completion
by Alexander Weber - Oct 14th 2002 11:01:46
> Sorry. Make that i=i+1 into i=$((i+1)).
Better works i=$i+1
Thx
[reply]
[top]
[»]
option -i in ssh
by martin - Aug 20th 2002 04:49:25
bash completion is great. Only one thing left I would like to see:
when using options like -i in ssh tab completion doesn't work.
I need somthing like this very often:
ssh -i .ssh/ident<TAB> host
to user another ssh-key pair. Unfortunately <tab> then is ignored.
May be I did not configured this correct!?
thanks for this good peace of code!
[reply]
[top]
[»]
Re: option -i in ssh
by Ian Macdonald - Oct 8th 2002 01:51:24
> bash completion is great. Only one thing
> left I would like to see:
> when using options like -i in ssh tab
> completion doesn't work.
> I need somthing like this very often:
> ssh -i .ssh/ident<TAB> host
> to user another ssh-key pair.
>
> thanks for this good peace of code!
OK, I've added this feature to the code. It'll be in the next release.
[reply]
[top]
[»]
great, but...
by dieterweb - Jun 5th 2002 18:49:03
this is a great project. but why gives me e.g.:
"cd /ho" -> "cd /home " (with a space after it!)
and not "cd /home/" as expected? i have suse 8.0.
dieterweb
[reply]
[top]
[»]
Re: great, but...
by Ian Macdonald - Jun 5th 2002 19:20:53
> this is a great project. but why gives
> me e.g.:
>
> "cd /ho" -> "cd /home
> " (with a space after it!)
>
> and not "cd /home/" as
> expected? i have suse 8.0.
See the TROUBLESHOOTING section of the README file. You are using an
unpatched bash 2.05. There's an official patch to fix this behaviour; or
you could just upgrade bash to 2.05a.
[reply]
[top]
[»]
Great hack, but ...
by Vladimir Ivanovic - May 2nd 2002 03:16:29
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
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?
Thanks.
-- Vladimir
P.S. I would be bummed if I can't get at least #1 fixed because I really
like this completion. Neat hack!
--
--- Vladimir
--------
Vladimir G. Ivanovic http://leonora.org/~vladimir
2770 Cowper St. vladimir@acm.org
Palo Alto, CA 94306-2447 +1 650 678 8014
[reply]
[top]
[»]
Re: Great hack, but ...
by Ian Macdonald - May 2nd 2002 03:38:23
> 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" == ?(.)?(.)/* ]];
> then'
> 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
. /etc/bashrc
fi
so it should be getting sourced. Are you sure that ~/.bashrc is even
getting sourced?
[reply]
[top]
[»]
Re: Great hack, but ...
by Vladimir Ivanovic - May 2nd 2002 17:42:34
> 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
> fi
>
> so it should be getting sourced. Are
> you sure that ~/.bashrc is even getting
> sourced?
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.
--
--- Vladimir
--------
Vladimir G. Ivanovic http://leonora.org/~vladimir
2770 Cowper St. vladimir@acm.org
Palo Alto, CA 94306-2447 +1 650 678 8014
[reply]
[top]
[»]
Re: Great hack, but ...
by roryh - May 13th 2002 06:47:06
It's just a wild guess, but does the same thing happen if you invoke your
shell as 'bash' instead of 'sh'? I believe that by invoking bash as 'sh' it
runs in sh-compatibility mode, which could prevent the advanced bash
features from functioning.
Just a guess.
[reply]
[top]
[»]
Re: Great hack, but ...
by FattMattP - Jul 3rd 2002 20:25:29
> 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:
I had the same problem and found that I had "set -o allexport"
set in my .bash_profile. Make sure you aren't executing that or executing
"set -a" in any of your bash related files.
[reply]
[top]
[»]
very nice
by rainerr - Apr 29th 2002 09:40:35
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=...
[reply]
[top]
[»]
sweet
by Dan Allen - Mar 25th 2002 23:45:13
Another gift from Linux Heaven, if there is such a place. One word
describes this addition to bash, 'logical'. If you type:
service <TAB>
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.
[reply]
[top]
[»]
Well I think it is pretty awesome....
by Travis Gerspacher - Feb 9th 2002 10:53:51
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.
[reply]
[top]
[»]
Integrated in the bash package of debian testing
by Olivier Berger - Jan 24th 2002 09:42:37
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.
[reply]
[top]
[»]
why bash?
by timecop - Dec 20th 2001 20:34:23
> 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?
[reply]
[top]
[»]
Re: why bash?
by Ian Macdonald - Dec 20th 2001 20:48:57
> > 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.
[reply]
[top]
[»]
Re: why bash?
by timecop - Dec 20th 2001 20:59:55
> 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.
[reply]
[top]
[»]
Re: why bash?
by Ian Macdonald - Dec 20th 2001 21:18:20
>
> 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.
[reply]
[top]
[»]
Re: why bash?
by brunson@brunson.com - Feb 6th 2002 18:39:02
> > 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?
[reply]
[top]
[»]
Or you could just use zsh.
by Dan Egnor - Dec 1st 2001 21:05:41
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...
[reply]
[top]
[»]
Re: Or you could just use zsh.
by Ian Macdonald - Dec 20th 2001 20:52:48
> 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.
| 
