3

We know some commands doesn't work on some files/directories. As an example we cannot use "cd" command on a file and when we try to press tab button to complete our line, the system doesn't show us any file for completion.

But I encountered an interesting scenario when I try autocomplete feature to complete a file name that finish with ".a". I can explain this scenario like below:

[root@myserver multipath]# ls -1
idlist
idlist.a
idlist.b
multipath.a
multipath.sh

I have these files in a directory.

  • When I type "vim m" and then press the "tab" button the system auto-complete this command as "vim multipath.sh".
  • When I type "vim idlist" and then press the "tab" button the system show me two option: "idlist" and "idlist.b". There is no "idlist.a" option.
  • And finally, when I use "cat (or anything else)" the system show me files that finish with ".a" (with all options). There is no confusing something at there.

What is the secret behind of ".a"? Why the system does not complete this files when we use vi/vim command?

  • 1
    Can you please show output of complete-filename idlist[TAB] ? Just to see If bash recognizes that file ending with .a or not. – C0deDaedalus Jul 10 '18 at 13:06
  • sorry i don't get it. what command do I use? is "complete-filename" a command? but if you accept "cat" command or something like that, the output is: cat idlist[tab] -- idlist idlist.a idlist.b -- . if I use vim: vim idlist[tab] -- idlist idlist.b -- – Gefolge Jul 10 '18 at 13:15
  • 1
    Just write complete-filename idlist[TAB]. Press TAB not Enter. Also what is your $SHELL ? – C0deDaedalus Jul 10 '18 at 13:29
  • i cannot use complete-filename command, i have not that. there is a command named "complete". But still if i try to do this, the output is same with output of "cat" (idlist idlist.a idlist.b). The problem is only with vi/vim as I see. and the shell: echo $SHELL --> /bin/bash – Gefolge Jul 10 '18 at 13:53
1

In my Kubuntu there is no /usr/share/bash-completion/completions/vim file, but the file

/usr/share/bash-completion/bash_completion

contains this line:

_install_xspec '*.@(o|so|so.!(conf|*/*)|a|[rs]pm|gif|jp?(e)g|mp3|mp?(e)g|avi|asf|ogg|class)' vi vim gvim rvim view rview rgvim rgview gview emacs xemacs sxemacs kate kwrite

Note there are lines for different tools, lots of them.

If I enable set -x and then vimtab, I see the pattern being used multiple times, finally even with an uppercase version of it, like this:

compgen -f -X '!!(*.@(o|so|so.!(conf|*/*)|a|[rs]pm|gif|jp?(e)g|mp3|mp?(e)g|avi|asf|ogg|class)|*.@(O|SO|SO.!(CONF|*/*)|A|[RS]PM|GIF|JP?(E)G|MP3|MP?(E)G|AVI|ASF|OGG|CLASS))' --

I temporarily removed |a from the bash_completion file. New instances of bash began to recognize *.a (and *.A) files.

I believe the pattern specifies files one wouldn't usually want to edit as text. This list (which is obviously case-insensitive) tells us a may denote a library in Unix. My guess is this is the reason to exclude it. Note o and so are other common extensions for binary files in Unix, they are also in the pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.