1

I've noticed an undesired behavior with bash tab completion when it comes to filenames and I'm wondering if anyone knows of a fix. Say I have a directory with a bunch of files but only one with a particular extension (say .c for example)

$ ls
file.c  file1  file2  file3

When I have a directory with a lot of files I know the extension of a unique file I want to reference I often find it useful to just reference it by extension using globbing (i.e. *.c). So I'll type ls *.c and then want to use <Tab> to make sure I was right about the file I was thinking of. However I've noticed this isn't working for me, at least not how I remember it working. I think I've narrowed down the issue to being something to do with the standard bash_completion script. On my Ubuntu system it's the script located at /usr/share/bash-completion/bash_completion. When I run bash without that script being sourced (or just turn bash programmable completion off entirely using shopt -u progcomp) I get the behavior I expect. I believe that's because tab completion then falls back to whatever the Readline default is. However it seems quite overkill for me to have to turn off programmable completion because I then lose a lot of nice tab completions when doing that so the tradeoff isn't really worth it.

I don't know this for sure but I'm assuming with bash the idea is supposed to be you have the default (tab)filename completion that Readline provides you and then the bash_completion package builds on top of it with more complicated and useful tab completion logic. However the bash_completion logic seems to change/break seems to previous behavior for my *.c case. Anyone run into this and know of a fix?

Improve this question
4
  • 1
    Does this answer your question? Bash autocomplete with wildcard
    – Saaru Lindestøkke
    Commented Apr 29 at 10:52
  • 1
    Definitely same type of problem but the solution isn't quite what I'm looking for. I'd prefer not to use those specialized glob-* readline functions for a few reasons. In my opinion the nice thing about tab completion is that it's one key for various completions so it would be nice to keep it that way instead of needing different key combos for different types of completions. Two, given that the original readline tab complete function works as I mentioned in my original post I think technically it should still work with the extended functionality of bash_completion.
    – eidna89
    Commented Apr 29 at 11:42
  • 2
    That's a pity that this does not match what you're looking for. Could you please edit/rewrite your question to show what you've found so far (e.g. the linked question) and why it doesn't address your problem? That prevents that other will suggest solutions you've tried already and were unsatisfactory.
    – Saaru Lindestøkke
    Commented Apr 29 at 11:44
  • I had the same problem, and it was pretty much the last straw and reason enough for me to disable bash-completion on the spot. Not only does it break *pat*<Tab> (which I use about 50 times a day), but it also inexplicably breaks a lot of other things that just work out of the box in plain bash. C-x*, which expands the pattern unconditionally regardless of how many file names it matches, is not an adequate replacement for <Tab> when it comes to wildcard expansion.
    – wildekat
    Commented Jun 6 at 16:52

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .