[SOLVED] Stop bash from replacing "~" with "/home/username" when TAB is pressed

dedec0 · 08-10-2014, 02:45 AM

Hello, I've been using Bash for many years, but recently an unusual behavior started happening too much, so I'm trying to get rid of it where it shows.

When we start typing a command, for example: "vim ~/a.od" and before ending the filename we hit TAB, so the shell completes that name for us, I expect it to and write "vim ~/a.odt ". But at some machines I get a horrible and way too long "vim /home/way/to/long/path/to/username/a.odt " as expansion. Even if there are more options, like two files "a.odt" and "a.ods" the tilde path is expanded on the command line.

[1] I want the expansion to happen when before args be passed to the programs, but without cluttering the command line.

"bind -v" / "~/.inputrc" are ignored for this ( bash's bug, maybe!? ).

And I found this thread, but it doesn't answer [1], which is important to happen!

What do you think? How to fix this? And the problem might be on the system /etc/bash_completion (or similar files); so how do we fix it without losing the rest of the benefits this/these files add?

jdkaye · 08-10-2014, 04:25 AM

I can't replicate that behaviour. Using the tab to autocomplete a command leaves the "~" form of the home directory intact. The line below was created using the autocomplete feature:

Code:

~$ nano ~/.profile

The output of my BASH_VERSION is as follows:

Code:

~$ echo $BASH_VERSION
4.3.11(1)-release

What is yours?
The autocomplete also works properly on the tty's.
jdk

dedec0 · 08-10-2014, 05:29 AM

The issue doesn't seem to be related to Bash version. And for distribution files (/etc/bash*), I have seen the issue on Ubuntu and a few others (not necessarily "Debianeses").

A few versions that have the problem right now, different distros:

GNU bash, version 3.2.48(1)-release (i486-pc-linux-gnu)
GNU bash, version 4.2.25(1)-release (i686-pc-linux-gnu)
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)

And the issue does not happen for all commands. For example (and "[xxx]" is a keypress here!) :

Code:

# This expands:
vim ~/t[TAB]

# This doesn't:
alias vviimm=vim[ENTER] vviimm ~/t[TAB]

Want me to paste the /etc/bash_completion file (which I mostly don't understand) ? And maybe .bashrc and /etc/bashrc?

But trying to get rid of this I just did a "silly change" to ~/.bashrc to delete the _expand() function:

Code:

(...)
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi

## 1. Should this properly fix it? Is it enough?
## 2. Any side effects? I don't know!
## 3. Should "__expand_tilde_by_ref()" be erased too?
function _expand() { return 0; }
(...)

Seems to work, but I wanted to be sure of what to do, instead of magical recipes of trial and error, undocumented effects¹. :-/

Edit:
¹ "undocumented" because the _expand* functions aren't clear for me to understand or don't have enough comments to do so.

dedec0 · 06-04-2015, 01:24 PM

I have found the exact cause of the related problem, and a solution.

If you could not reproduce, it may be because not all distros should have the same setup of configuration files. In my case, it is an Ubuntu machine. And I have seen it with Debian too (maybe it's common to many Debian derivatives).

The culprit: /etc/bash_completion

The culprit lines (already fixed, by commenting them and adding a "return" to leave no errors) :

Code:

# This function expands tildes in pathnames
#
_expand()
{

    #   # FIXME: Why was this here?
    #   #[ "$cur" != "${cur%\\}" ] && cur="$cur\\"
    #
    #   # expand ~username type directory specifications
    #   if [[ "$cur" == \~*/* ]]; then
    #           eval cur=$cur
    #   elif [[ "$cur" == \~* ]]; then
    #           cur=${cur#\~}
    #           COMPREPLY=( $( compgen -P '~' -u $cur ) )
    #           return ${#COMPREPLY[@]}
    #   fi
    return
}

I don't know if the empty return could have some bad side effect, since it should be returning something. But it has been a few weeks, and I have not noted anything wrong.

It took me a lot of time, but this can be useful to someone else too.