Bash command completion puts backslash in front of beginning dollar sign

Thank your for the report.

Could you execute the following command and send us the output

echo $PS1

jtholmes wrote:
> Thank your for the report.
>
> Could you execute the following command and send us the output
>
> echo $PS1
>
> ** Changed in: bash (Ubuntu)
> Sourcepackagename: None => bash
>
xeno@radioflyer:~$ echo $PS1
${debian_chroot:+($debian_chroot)}\u@\h:\w\$
xeno@radioflyer:~$
---
Sorry I didn't get back to you further. Above is the echo you wanted.
Also, I have rebooted several times today to see if I could evoke the
bug again, but it always comes back with the normal status manager icon.
  Unless you have other info, I guess my little bug is dormant or gone
now. I have not upgraded since it started. I don't know what else to
tell you for now, except have a good weekend.

Sincerely, Xeno

--
The only sustainable organizing methods focus not on scale,
but on good design of the functional unit,
not on winning battles, but on preservation.

Ok

Interseting, if it occurs again then open another terminal
Applications -> Accessories -> Terminal
and see it the newly opened terminal has the problem.

Let me know if this occurs in the next week or so and if not
then with your permission we will close this bug report.
thanks
jt

Is this a duplicate of bug 19364?

It may be related, but it's not what I was trying to describe. I have since seen this on Kubuntu shell. Originally I got it on UbuntuME. I just tried on my Ubuntu, and it doesn't manifest the bug there.

xc

Really? I can easily repro bug 19364 on a Gutsy (Ubuntu 7.10) system. Could you elaborate on how this one is different? Or is it just that you want it separately tracked for UbuntuME?

... Or did two different bugs get mixed up here? I really don't understand the comments about PS1 and Status Manager above.

vnix$ cd $HOM<TAB>
vnix$ cd \$HOME
bash: cd: $HOME: No such file or directory

vnix$ bash --version
GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

vnix$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

Not at all. If the bug is more general, then let it be known. I just tried it again, and I don't get it on my Gutsy install. Perhaps there is something about my configuration on Gutsy that differs from what I have on Kubuntu and UbuntuME on the same machine, but I only get the symptom on the latter two. Presumably this DIFFERENCE symptom will also be of interest. Thank you for the feedback. I tried your example exactly, and mine works. I also tried with both set -o vi and set -o emacs, and I get the same thing: WORKS ON GUTSY. If anyone can pin down what I'm doing differently, it sounds like that will be an important key. I've also noticed all my CentOS systems DO NOT have the problem (an anomaly since most of the times I have worse luck with CentOS than with Ubuntu). Here is my env:

SSH_AGENT_PID=5741
TERM=xterm
DESKTOP_STARTUP_ID=
SHELL=/bin/bash
XDG_SESSION_COOKIE=9faf89b80ff29cdd0f58790047b13d00-1203704702.416442-40037354
GTK_RC_FILES=/etc/gtk/gtkrc:/home/xeno/.gtkrc-1.2-gnome2
WINDOWID=67108959
USER=xeno
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.flac=01;35:*.mp3=01;35:*.mpc=01;35:*.ogg=01;35:*.wav=01;35:
GNOME_KEYRING_SOCKET=/tmp/keyring-tea90a/socket
SSH_AUTH_SOCK=/tmp/ssh-KbYHpL5706/agent.5706
USERNAME=xeno
SESSION_MANAGER=local/teamfuji:/tmp/.ICE-unix/5706
DESKTOP_SESSION=default
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
GDM_XSERVER_LOCATION=local
PWD=/home/xeno
GNOME_KEYRING_PID=5703
LANG=en_CA.UTF-8
GDM_LANG=en_CA.UTF-8
GDMSESSION=default
HOME=/home/xeno
SHLVL=2
GNOME_DESKTOP_SESSION_ID=Default
LOGNAME=xeno
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ita010goAJ,guid=d5948f4e020d653b90c6b90047bf1380
XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/share/gdm/
LESSOPEN=| /usr/bin/lesspipe %s
WINDOWPATH=7
DISPLAY=:0.0
LESSCLOSE=/usr/bin/lesspipe %s %s
XAUTHORITY=/home/xeno/.Xauthority
COLORTERM=gnome-terminal
_=/usr/bin/env
xc

Do you have the standard .bashrc (i.e. is /home/xeno/.bashrc identical to /etc/skel/.bashrc) or do you have any other pertinent customizations which may be overriding the default Bash configuration on Ubuntu? What does complete -p bash print for you? (For me it says complete -o filenames -F _longopt bash)

Actually, ignore the question about "complete -p bash", it's not relevant here.

But if you instead could try to run bash with verbose diagnostics on for a while, that might be useful.

The verbose diagnostics will spew out stuff on the terminal when you attempt completion, as well as when commands execute. You enable it with "set -vx" and turn it off with "set +vx".

Like this:

vnix$ set -vx
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
++ echo -ne '\033]0;era@indeed: ~\007'

vnix$ echo $HOM<TAB>
vnix$ echo $HOME<RET>
+ echo /home/era
/home/era
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
++ echo -ne '\033]0;era@indeed: ~\007'

vnix$ cd $HOM<tab>
+ local 'IFS=
' 'cur=$HOM' i j k
+ [[ $HOM == ?(\\)\$* ]]
+ COMPREPLY=($( compgen -v -P '$' -- "${cur#?(\\)$}" ))
 compgen -v -P '$' -- "${cur#?(\\)$}"
++ compgen -v -P '$' -- HOM
+ return 0
\$HOME
vnix$ cd \$HOME<RET>
+ cd '$HOME'
bash: cd: $HOME: No such file or directory
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
++ echo -ne '\033]0;era@indeed: ~\007'

vnix$ set +vx
set +vx
+ set +vx

vnix$

Also the output of complete -p cd might be useful.

vnix$ complete -p cd
complete -o filenames -o nospace -F _cd cd

It seems that if I remove the "-o filenames" it works as hoped.

Here you go:
xeno@teamfuji:~$ set -vx
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
++ echo -ne '\033]0;xeno@teamfuji: ~\007'
xeno@teamfuji:~$ echo -ne $HOME
echo -ne $HOME
+ echo -ne /home/xeno
/home/xenoecho -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
++ echo -ne '\033]0;xeno@teamfuji: ~\007'
xeno@teamfuji:~$ complete -o filenames -o nospace -F _cd cd
complete -o filenames -o nospace -F _cd cd
+ complete -o filenames -o nospace -F _cd cd
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
++ echo -ne '\033]0;xeno@teamfuji: ~\007'
xeno@teamfuji:~$ set +vx
set +vx
+ set +vx
xeno@teamfuji:~$

So what does "complete -p cd" print for you, on a freshly booted system?

This is a bug in the bash-completion package

I can confirm this on a current hardy install.

I've prepared an updated package in my PPA which should fix the bug you reported.

If you're using hardy I'd appreciate it if you could test it and report whether your bug is indeed fixed and also whether you experienced any other regressions.

You can get the package from here:
http://launchpadlibrarian.net/13042048/bash-completion_20060301-3ubuntu2%7Eppa2_all.deb

To install it:
wget http://launchpadlibrarian.net/13042048/bash-completion_20060301-3ubuntu2%7Eppa2_all.deb
sudo dpkg -i dpkg -i bash-completion_20060301-3ubuntu2~ppa2_all.deb

To go back to the original package, do this:
sudo aptitude install bash-completion/hardy

If I don't get reports of regressions I'll try to get this version into hardy.

Thanks for your help!

I had to revert the fix for now because it caused a regression :(

I first got this on UbuntuME under Feisty, but now I'm also seeing it on Server and regular Desktop, so presumably now everybody has the disease. I wish someone had listened earlier. Attack of the killer backslashes!

Yes. I think it's bug of bash_completion in /etc.
If you turn it off in your .bashrc, no this problem. Once you turn it on, it happens.
I'm running Ubuntu 8.04.1 Hardy on Dell XPS M1530.

I fix this one by editing this file.
------------------------------------------------------------------------------------------------
If you're not interested in seeing the details, please download the file and

sudo cp /etc/bash_completion /etc/bash_completion_bak
sudo cp bash_completion /etc/bash_completion

exec bash
------------------------------------------------------------------------------------------------

Also you can do it by yourself
open /etc/bash_completion
find "complete -F _cd $nospace $filenames cd"
remove $filenames
save it. That's it.

I don't know if it causes any regression. If so, please post it. Thanks a lot.

Sorry guys. I just find a bug for fixed version.
ex: directory A\ B/
      cd A{tab}
      cd A B

so actually it remove backslash before any special character. Stilll working on it.

So far, my fix is to comment "complete -F _cd $nospace $filenames cd" in /etc/bash_completion.

Hope it will work.

The upstream Debian bug has a patch which is described as reimplementing the -f (aka -o filenames) behavior on an as-needed basis. I haven't tried it, but the description sounds like it could be worth considering while Debian continues to ponder this case.

Fixed in bash-completion 1:1.0-1, now in karmic:

    - fixed completion of environment variables, thanks to Morita Sho
      (Closes: #272660)

Well, that may be fixed, but my latest upgrade on my System76 laptop sure STILL has the problem.

And my Ubuntu Server 9.04 with latest updates and right after a reboot to boot:
$ cd $TM<tab>
$ cd \$TMP
-bash: cd: $TMP: No such file or directory
$ uname -a
Linux leopard 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux
So, I don't know where the fix is, but I am not seeing it yet.

Same here as Xeno on multiple updated 9.04 systems. The comment out trick seems to "work".

The backslash is gone in karmic, but the behavior is not fixed. With the karmic (and upstream debian) bash-completion package, environment variables still do not expand.

$ cd $HOME<tab>
$HOME

As others have noted, simply removing $filenames breaks the expansion. For me, the behavior of $dirnames in its place is at least tolerable (you must type a slash in order to get the path to expand). I would consider this bug still open.

Until it gets fixed properly, the workaround is easy to apply...

Workaround diff for the karmic bash_completion:
--- /etc/bash_completion 2009-06-01 06:33:54.000000000 -0400
+++ bash_completion 2009-07-20 10:52:21.000000000 -0400
@@ -3236,9 +3236,9 @@
  return 0
 }
 if shopt -q cdable_vars; then
- complete -v -F _cd $nospace cd
+ complete -v -F _cd $nospace $dirnames cd
 else
- complete -F _cd $nospace cd
+ complete -F _cd $nospace $dirnames cd
 fi

 # a wrapper method for the next one, when the offset is unknown

Hello,

I am using ubuntu 9.04 and I did the change as gjzeus suggested:

$ diff /etc/bash_completion /etc/bash_completion.backup
3171c3171
< complete -F _cd $nospace cd
---
> complete -F _cd $nospace $filenames cd

The problem reported here is solved but I observed a I found a side effect when "cd" is used to navigate through a chain of directories that just contain one directory.

Lets say I have the following structure:
example$ tree
.
`-- levelOne
    `-- levelTwo
        `-- levelThree

Beofre this change if it was typed:
example$ cd level [tab][tab][tab]
the command was expanded itself by the shell (only if there was a single directory in the current directory)

With this change, when tab is pressed it just displays the name of the directory that is in the current directory instead of auto completing the command:
example$ cd levelOne [tab]
levelOne

Do you observe this behaviour as well?

Thanks,
Juan Garibay

Reproduced on natty,

ls $HOME/<tab>

produces

ls \$HOME/

Reproduced on natty.

Also all the problems described in #26 and #27 are still present in Lucid.

I'm seeing this on Ubuntu 12.04. (I installed beta2 a couple of weeks ago and have applied all updates since then).

I have commented out the entire body of /etc/profile.d/bash_completion.sh (due to a different issue).

With a newly created account, no changes to any $HOME/.* files :

$ uname -a
Linux kvetch 3.2.0-23-generic-pae #36-Ubuntu SMP Tue Apr 10 22:19:09 UTC 2012 i686 i686 i386 GNU/Linux
$ echo $BASH_VERSION
4.2.24(1)-release
$ dpkg -l bash bash-completion
[SNIP]
ii bash 4.2-2ubuntu2 GNU Bourne Again SHell
ii bash-completio 1:1.3-1ubuntu8 programmable completion for the bash shell
$ echo $HOME/<tab>

produces

$ echo \$HOME/

More information:

I see the same problem with bash-4.2 built from source.

Restoring the original version of /etc/profile.d/bash_completion.sh doesn't change the behavior.

I see this behavior on 12.04 with
GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu)

I get the same behavior even when I remove /etc/bash_completion and /etc/bash_completion.d

repro:
sudo mv /etc/bash_completion /etc/bash_completion.backup
sudo mv /etc/bash_completion.d /etc/bash_completion.d.backup
env -i HOME=$HOME DISPLAY="$DISPLAY" xterm -e bash --login --noprofile --norc

in new xterm:

bash-4.2$ cd $HOME<tab>
bash-4.2$ cd $HOME <cursor> <--- just adds a space

bash-4.2$ cd $HOME/<tab>
bash-4.2$ cd \$HOME/<cursor> <--- annoying bug (adds backslash before $)

bash-4.2$ xyz $HOME/<tab>
bash-4.2$ xyz \$HOME/<cursor> <--- same behavior for any command (not just cd)

So maybe this is the bash default completion behavior?

Note: in contrast, on Ubuntu 10.04 with
GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)

I do not get the backslash:

repro:
sudo mv /etc/bash_completion /etc/bash_completion.backup
sudo mv /etc/bash_completion.d /etc/bash_completion.d.backup
env -i HOME=$HOME DISPLAY="$DISPLAY" xterm -e bash --login --noprofile --norc

in new xterm:

bash-4.2$ cd $HOME<tab>
bash-4.2$ cd $HOME <cursor> <--- just adds a space (same as Ubuntu 12.04)

bash-4.2$ cd $HOME/<tab>
bash-4.2$ cd /home/acorn/ <--- no bug! expands as expected!

bash-4.2$ xyz $HOME/<tab>
bash-4.2$ xyz /home/acorn <--- no bug! expands as expected!

So maybe this is a regression in bash itself?

Uninstall the "bash-completion" package give better results!

I just saw this same issue in my Manjaro system today. I type

cd $HOME/my

hit tab
and I get

cd \$HOME/myHome

My bash version is 4.3.46 I am uncertain as to what my bash-completion version is. I know that this is not a Manjaro problem site but was looking here for the real fix

Upgraded to 20.04 and this issue has appeared.
I've used variables
DD=/mnt/Ddisk
since I been using Ubuntu, at least 14.04.
vi $DD/misc/filena <TAB>
worked consistently until 20.04.1 release.
This release is the first time that this has occurred. It seems to have been
unfixed in this release.

@Ken Blackburn: Probably better to create a new bug report, even if you think this is a regression. (Probably link to this old bug report in the new one.)