Bash Completion In C7
Hello there,
while bash completion was working great to me in CentOS6, since I’m using C7 I spend my day stuck on completion not working the way it should.
The bad situations I’m facing are:
– it doesn’t expand *foo whereas there are *foo-named files in current dir, for instance:
# rm *foo
will show nothing whereas there’s a file barfoo in curdir.
– completion takes 10 sec to propose me something, I don’t have an
example right here but I’d prefer no completion instead of a
completion that hangs for more than 3 sec.
I don’t care much about command-specific completion (command –switches and so on), but it generally fails in listing files in curdir, that is a huge fail to me.
I have this installed:
bash-4.2.46-30.el7.x86_64
bash-completion-2.1-6.el7.noarch bash-completion-extras-2.1-11.el7.noarch
Didn’t touch global or user prefs around bash completion if there are.
Am I missing something or is it just an itchy fail, real pain in the *ss?
Regards,
8 thoughts on - Bash Completion In C7
Tab completion finishes a single word, given a string that appears at the beginning of a list of candidates.
Wildcard expansion (Ctrl+x, e) will expand a word containing a wildcard to multiple words on the command line, usually so that you can remove some matches.
Neither will do specifically what you’re trying to do, as far as I
know.
Hello Gordon,
Wrong, tab completion proposes the list of candidates if there are several, and it only finishes a single word automatically if there’s only one match for the pattern. At least I never experienced tab completion how you’re describing it.
This works fine in CentOS 6, and anywhere with bash 2 and 3, I used such completion pattern (ls *foo) for years on various systems. I hardly see how this is ambiguous unless completion doesn’t prioritize *foo matching on files.
Irrelevant example here, I’m not talking about remote shells. On a remote shell I would expect extra delays, anyway, but this is not what I’m dealing with here.
I tried disabling programmable completion entirely (`complete -r`), since I don’t need it and find it unreliable and it now works as always for file matching patterns. That was a tip, thanks!
Regards,
Since you don’t want what it provides you can either remove the bash-completions* packages or append “complete -r” to your ~/.bashrc which turns off all custom completions leaving just pathname completion
— I also use “complete -o dirnames cd” so that the completions for the cd command are limited to directory names. The bash-completions project didn’t stand still nor did the tools it uses so you might consider submitting an upstream bug report.
/mark
Perhaps a miscommunication.
Hello Mark,
Yes probably. In fact, I think I got twisted by the name “bash completion”, I thought it was just what one can call tab-completion, that we had for years (and often use!). Obviously it’s another thing sitting on top of it, that I don’t need :-).
Regards,
Hi Gordon,
Hah. You may laugh, but talking about mis-communication, you’re definitely right. In my former saying “there are *foo-named files in current dir”, I` I was expecting: ` ` matches
didn’t mean that I had files like:
1.foo-named
2.foo-named but files named like *foo (IOW, maching the pattern *foo), id est:
1.foo
2.foo
(my use of “-named” was confusing obviously)
thus, from `ls *foo
1.foo
2.foo I well know that to match “1.foo-named”, I should use `ls *foo*
(trailing *) and I’m sure that you know that `ls *foo
1.foo.
I think we did now understand each other? ;-) to me, the subject is over, I’ve did `complete -r` and voila.
Regards,
I didn’t.
Hello Gordon,
I’m afraid I see the same behaviour since Bash 2.0 :-/.
Must confess that I quite never use Alt+ and Ctrl+ key combinations, saving me from finger stretching.. I’m reading the man about all that now, instructive, thanks!
Regards,