2

I just recently started out with MacOS, but there one some strange completion behaviour with the bash shell (compared to OpenSuse Linux with tcsh where I come from) that is bugging me:

For example, when I am in $HOME and write Pu on the command line, followed by tabbing for completion, I expected that one of the options shown would be my Public/ directory. However, as long as there are executable files, the completion never shows directories that share the same prefix. Only after entering Publ, the tab completion gives me Public/ as there are no more executables with that prefix.

So my question would be, is there an option to have the completion directly show executables and directories with the given prefix?

I already tried upgrading to bash 4 and installing bash-completion via homebrew but that did not help. I suspect that either the MacOS readline behaves differently or that there are some more setting for .inputrc which I do not know about.

I further know that by starting with ./ I only get directories. This is the bandaid that I use at the moment.

Improve this question
4
  • Did you try pressing the Tab button twice? That will show a list of completions as far as I am aware.
    – Anton Todorov
    Commented Aug 11, 2015 at 15:10
  • Yes, I did. I will add this to the initial question to clarify.
    – shiin
    Commented Aug 11, 2015 at 17:36
  • On my Mac running Mavericks, zsh is behaving as you describe, but bash find directly directories and executables at first. Could you add within your question: which shell you are using, and the output of ls -ld Pu*?
    – athena
    Commented Aug 11, 2015 at 22:42
  • I specified that I used bash in the question. The output of the ls is just the Public/ folder. The executables starting with Pu are in some directories of the PATH. You actually explained the behaviour nicely in your answer and I could verify it.
    – shiin
    Commented Aug 11, 2015 at 23:29

3 Answers 3

Reset to default
1

For most shells with a file expansion function what is expanded in argv[0] position is an executable found within one of the directories of the PATH variable.

If you want to find directories when entered as 1st argument within bash or zsh, simply modify PATH as follows:

PATH=${PATH}:.

and test it with:

Pubtab

For tcsh the equivalent modification of PATH is obtained with:

setenv PATH ${PATH}:.

Warning

To include . into the PATH variable is a security risk. Since this modification any file in the directory where you are will be found as a standard command. This might lead you to execute files you would never had tried to execute otherwise: executables which will cause a core dump in a development directory, or binaries which will make you execute commands to get priviledged access to your system.

This risk is the same for any Unix like OS.

Improve this answer
2
  • Thank you. I just checked on my old PC at University and there the default PATH actually contained the . - so that was the reason why the completion worked different there. But regarding your warning, I won't add it back and get used to using ./ if I want paths in my completion. Thank you.
    – shiin
    Commented Aug 11, 2015 at 23:25
  • Wise and secure move :).
    – athena
    Commented Aug 11, 2015 at 23:47
1

as far as I know, it's a feature, not a bug.

you could just change to tcsh, here is a guide (eventually you have to install it via homebrew, then adapt the path)

Improve this answer
2
  • Thank you for the answer. I did not know that it was considered to be a feature - or at least one that cannot be disabled. I might give tcsh another try, but I actually wanted to switch to something that is more widely used.
    – shiin
    Commented Aug 11, 2015 at 17:39
  • Oh.. OK but you may try to set bash options (shopt shell options) to get that working....
    – Schwertspize
    Commented Aug 11, 2015 at 17:42
-3

Try it with ./Pub[tab]

the ./ makes it the current directory to start the tab-completions from

(I'd like to know know how this isn't usefull, as it works that way on Linux too?)

Improve this answer
1
  • I guess it is because I already mentioned this option in my question. But it is a valid point and I should probably state this more clearly in my initial question.
    – shiin
    Commented Aug 11, 2015 at 17:36

You must log in to answer this question.

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