Typing "prg $HOME/<tab>" expands to "prg \$HOME/"

[Thomas Schweikle]

Typing "prg $HOME/<tab>" expands to "prg \$HOME/" quite annoying, shall expand to "prg $HOME/" listing all directories and files available for expansion, not creating an escaped string from $HOME. It should KEEP $HOME, not expanding it to your home directory as with some program named done!

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: bash-completion 1:1.3-1ubuntu6
Uname: Linux 3.0.9 x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Wed Nov 16 00:31:37 2011
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: bash-completion
UpgradeStatus: No upgrade log present (probably fresh install)

[Jamie Strandboge (jdstrand)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Daniel Black (daniel-black)]

reported upstream: http://alioth.debian.org/tracker/index.php?func=detail&aid=313501&group_id=100114&atid=413095

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[jimav (james-avera)]

This is a REGRESSION. It used to expand $variable to its value rather than generating \$variable
So, for example, if file.txt exists in $HOME, typing

   ls $HOME/fil<tab>

used to generate

  ls /home/user/file.txt

but now gives you

  ls \$HOME/file.txt

which is useless.

Either it should be fixed to not generate the backslash, or else the changes reverted so the old way works (i.e. replacing $variable with its value)

[Peter Cordes (peter-cordes)]

$HOME is a good example as a testcase, but a terrible example of it actually being a problem, because ~/file.txt is easier to type anyway.

$OLDPWD is more annoying. I think progcomp used to expand the variable on your cmdline, and then of course completion just worked normally. I think that expansion was a bug, and now we're exposed to this bug.

[Mathew Hodson (mhodson)]

On Trusty,

$ prg $HOME/fil<Tab>

produces

$ prg /home/mathew/file.txt

Is this still an issue? Does it affect Precise?

[Simon Déziel (sdeziel)]

This affects Precise:

  ls $HOME/.bas<tab>

turns into:

  ls \$HOME/.bash

# apt-cache policy bash bash-completion
bash:
  Installed: 4.2-2ubuntu2.6
  Candidate: 4.2-2ubuntu2.6
  Version table:
 *** 4.2-2ubuntu2.6 0
        500 http://ca.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
        100 /var/lib/dpkg/status
     4.2-2ubuntu2 0
        500 http://ca.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
bash-completion:
  Installed: 1:1.3-1ubuntu8.1
  Candidate: 1:1.3-1ubuntu8.1
  Version table:
 *** 1:1.3-1ubuntu8.1 0
        500 http://ca.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:1.3-1ubuntu8 0
        500 http://ca.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

[jimav (james-avera)]

Not fixed in Ubuntu 15.10.
The problem occurs if completion expands to a name containing spaces. For example "Virtual Box VMs" in $HOME

STEPS TO REPRODUCE:

1. mkdir $HOME/'DIR WITH SPACES'
2. echo $HOME/DIR<tab>

RESULTS:
  echo \$HOME/DIR\ WITH\ SPACES

EXPECTED RESULTS:
  echo $HOME/DIR\ WITH\ SPACES

$ apt-cache policy bash bash-completion
bash:
  Installed: 4.3-14ubuntu1
  Candidate: 4.3-14ubuntu1
  Version table:
 *** 4.3-14ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status
bash-completion:
  Installed: 1:2.1-4.1ubuntu2
  Candidate: 1:2.1-4.1ubuntu2
  Version table:
 *** 1:2.1-4.1ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status

[Mathew Hodson (mhodson)]

I still can't reproduce with Trusty even with a directory with spaces.

$ mkdir $HOME/'DIR WITH SPACES'
$ echo $HOME/DIR<Tab>

produces

$ echo /home/mathew/DIR\ WITH\ SPACES/

$ apt list bash bash-completion
Listing... Done
bash/trusty-security,trusty-updates,now 4.3-7ubuntu1.5 amd64 [installed]
bash-completion/trusty-updates,now 1:2.1-4ubuntu0.1 all [installed]

[jimav (james-avera)]

Maybe it has something to do with option settiings. Mathew, can you try with the following bash variables set to see if the problem appears for you? Also, BASH_VERSION='4.3.42(1)-release' pm wily, if that matters

BASH=/bin/bash
SHELL=/bin/bash
BASHOPTS=cdspell:checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:histappend:histreedit:hostcomplete:huponexit:interactive_comments:progcomp:promptvars:shift_verbose:sourcepath
CDPATH=.:..:../..
HISTIGNORE='pwd:exit:fg:fg *:bg:bg *:l:history:cd:dist_my_setup*'
HISTSIZE=20000
IFS=$' \t\n'
LANG=en_US.UTF-8
LANGUAGE=en_US
OPTERR=1
OPTIND=1
SESSIONTYPE=gnome-session
SHELLOPTS=braceexpand:hashall:histexpand:history:interactive-comments:monitor:vi

[Daniel Barrett (dbarrett-m)]

This bug used to affect me in 14.04 LTS. Since upgrading to 15.10, the bug no longer occurs for me.

Just another data point.