4

I am using a minimal install of CentOS 8.

If I have a folder called "some_folder" in my home folder, on the command line I can do:

some <now hit tab, and bash completion resolves to "some_folder">

However, if I have a file called "my_file" in my home folder, at the prompt, I type:

my_ <now hit tab, and NOTHING happens, bash completion does not work>

Apparently, I have to go back and type ./my_ before hitting tab(!?). Do you know how I can get CentOS to tab complete for files in the same way that it does for folders?

Improve this question

3 Answers 3

Reset to default
3

Your current directory isn't (or shouldn't be) in your $PATH, so it's not a valid location in which to find executables. In this example, my_ is the prefix to a command, and so will not be found in your current directory:

my_<tab>

In this example, the my_ is an ordinary file and can be found by tab completion:

cat my_<tab>
Improve this answer
5
  • My current directory is not in my $PATH. Are you saying that it will only tab complete if my_file is an executable? It does autocomplete after cat as you suggest but I'm still confused. ok, next test, I set chmod 777 my_file and try to do my_ and it still won't complete. Are you saying that it will only autocomplete from locations that are on the path, and will not autocomplete an executable file, even if that is in my pwd? Is that standard behaviour on most distros?
    – YorSubs
    Commented Nov 12, 2020 at 15:57
  • 1
    Yes exactly that, it must be executable and in $PATH. This behaviour is from the shell rather than the distro (I would expect the vast majority of shells to behave in the same manner).
    – bxm
    Commented Nov 12, 2020 at 16:13
  • I've been doing lots of work on PowerShell for the last few years (not been touching Linux servers much) and PowerShell allows you to tab a file in that in way (which makes sense as if you tab complete a .txt file for example, then hit Enter it will open that file with an associated app. As you say, I guess it's just particular to the philosophy of Linux shells that I forgot.
    – YorSubs
    Commented Nov 12, 2020 at 16:31
  • I just installed pwsh on CentOS there and confirmed that the behaviour for pwsh on Linux is the same as Windows. i.e. if I type in my_ (without a ./) and then hit TAB it adds the ./ to resolve the full filename as ./my_file.
    – YorSubs
    Commented Nov 12, 2020 at 16:41
  • Windows and PowerShell a different beast. Windows will attempt to "run" any given file. The responses will range from execution for things like .cmd and .exe (etc), to opening in the associated program for registered extensions, and just telling you there's nothing associated for everything else. Sounds like pwsh is bringing some Windows idioms along with it for least surprise (but also accommodating other shell norms by prefixing ./ for you).
    – bxm
    Commented Nov 12, 2020 at 17:07
1

If there isn't a command preceding my_ then the shell will only complete with the names of local directories, or executable files that are in the PATH. By default the current directory is not in the PATH for reasons of best practice.

If you were to do ls my_<TAB> then it should complete for you.

Improve this answer
-1

One way could be by adding the current directory to your PATH environment variable in your profile, but in this way it could be dangerous since you can execute scripts without doing it on purpose (without ./) :

export PATH="$PATH:."
Improve this answer
3
  • 1
    Whilst this would "solve" the problem as described, it's generally not a good idea as you might end up doing something like running a PWD executable that name clashes with a system binary. The impact of this could run the gamut from "surprise", "confusion" and "inconvenience" at the low end all the way to "dangerous" and "potentially compromising security" at the high end.
    – bxm
    Commented Nov 12, 2020 at 16:09
  • @bxm: It is adding the current directory at the end of the search path, so system will take priority. It would still help running something that should not be, though. I agree it would be a bad idea.
    – Ángel
    Commented Nov 13, 2020 at 0:47
  • Agreed that adding it at the end is of lower risk, but $PATH is not immutable. All it takes is some other sourced script to append to $PATH later and you’re back into realms of unintended consequences.
    – bxm
    Commented Nov 13, 2020 at 8:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .