/usr/bin/which and /usr/bin/xargs do not find commands in $HOME/bin

[Georg]

Binary package hint: debianutils

I'm a little bit at loss with this problem and don't know where to start debugging it. My $PATH is PATH='~/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games', but neither 'which' nor 'xargs' find executable shell scripts in $HOME/bin. However, the bash magically 'knows' about these commands and can execute them. Bash-completion with <TAB> works for them as well. So I suppose that both which and xargs are somehow broken. However, 'which' is able to find commands in /usr/bin, /usr/sbin, /bin and /sbin. So this is very strange, looks as if 'which' and 'xargs' ignore the current $PATH.

I would appreciate all help with this.

Thanks.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: debianutils 3.2.2
ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-23-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri Jul 23 23:30:01 2010
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
SourcePackage: debianutils

[Georg (georg-lippold)]

Another strange thing is that which works in a non-X terminal (by switching to a text-mode console via Ctrl-Alt-F1). When I use which there, it works, but both in uxterm and GNOME Terminal I don't get the correct output.

[Dustin Kirkland  (kirkland)]

What if you replace the "~" with "$HOME" in your $PATH?

[Georg (georg-lippold)]

So in my .bash_profile, PATH is set as follows:

# set PATH so it includes user's private bin if it exists
if [ -d $HOME/bin ] ; then
    PATH=$HOME/bin:"${PATH}"
fi

In an xterm/uxterm/gnome-terminal session, this results in a PATH set to

$ set | grep ^PATH=
PATH='~/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games'

In a terminal login shell (via console1 (Ctrl-Alt-F1), or via ssh localhost) this results in a PATH of

$ set | grep ^PATH=
PATH=/home/lippold/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

interestingly, the PATH in the xterm session has quotes and a ~, whereas the PATH in the terminal session has no quotes and an expanded $HOME instead.

I honestly cannot imagine what causes this, but it is very weird that bash behaves differently in an xterm and a non-xterm login.

[Georg (georg-lippold)]

So my reasoning would be that an xterm is not a login shell, and therefore .bash_profile is not being executed. My .bash_profile is attached, and I modify the path in there. What I'm wondering is why it worked until a few days/weeks back and suddenly stopped working?

As a workaround, I tried to create a $HOME/.Xdefaults file as described here

http://forums.macosxhints.com/showthread.php?t=9282

Basically what I did was creating a $HOME/.Xdefaults with the contents

XTerm*.LoginShell: True

and then added a new startup application (System -> Startup Applications -> New...) containing the line

xrdb -all $HOME/.Xdefaults

because Ubuntu does not honor $HOME/.Xdefaults on startup (i.e. no xrdb is started automatically for that, or at least not for me).

This is a workaround, because now my xterms also source my .bash_profile and everything works.

[Georg (georg-lippold)]

OK, I found the culprit... seems as if my .profile included a line

PATH=~/bin:$PATH

I replaced that with

PATH=$HOME/bin:"${PATH}"

and now it works

[Dustin Kirkland  (kirkland)]

Thanks for the followup!

[The Gavitron (me-gavitron)]

Had the same issue in Latest Stable Lucid, and comment #7 was the problem and fix.

PATH=~/bin:$PATH

fails, but

PATH=$HOME/bin:$PATH

works.

Changed bug status to "confirmed" since
a) I can confirm the behavior
b) http://www.faqs.org/docs/bashman/bashref_28.html suggests this should behave otherwise
c) the myriad scripts in /etc that prime tab-completion to behave in (imho: awful) context-sensitive ways are ubuntu specific.

[The Gavitron (me-gavitron)]

edit: in the above comment, I singularly reference tab-completion as broken, when in fact /usr/bin/which and /usr/bin/xargs are also failing for me when using tilde expansion. I still blame the /etc/bash_completion cruft, but I probably can't hang it all at the feet of ubuntu.

[Maarten Bezemer (veger)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem seems to have been fixed with some of the updates, at least I tried and it seems to be working for me (Kubuntu 11.10). It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect 609146 and any other logs that are relevant for this particular issue.

[Launchpad Janitor (janitor)]

[Expired for debianutils (Ubuntu) because there has been no activity for 60 days.]

[Petr Gladkikh (petrglad)]

This bug affects me. which does not find any programs in dirs starting with '~' however bash starts them with no problem.

Ubuntu release : "Ubuntu 13.04"
uname -a : Linux the-host 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
My $PATH:
/home/petr/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:~/bin:~/opt/apache-maven-3.0.5/bin:~/opt/adt-bundle-linux-x86_64-20130219/sdk/platform-tools/:~/opt/adt-bundle-linux-x86_64-20130219/sdk/tools/:~/opt/android-ndk-r8e/:~/opt/bin/

Path for '~/bin' is actually duplicated by '/home/petr/bin' here so it works. But "which" does not show programs from any of
~/opt/apache-maven-3.0.5/bin
~/opt/adt-bundle-linux-x86_64-20130219/sdk/platform-tools/
~/opt/adt-bundle-linux-x86_64-20130219/sdk/tools/
~/opt/android-ndk-r8e/
~/opt/bin/

[Petr Gladkikh (petrglad)]

And by the way workaround replacing ~ with $PATH helps in my case. But nonetheless I believe that behavior of 'which' should be consistent with shell's lookup.

It is hard to believe that this problem have not be noted before. If this is some known issue, can anyone point to explanation why it is not corrected already?