Apparent bug with $PATH in bash

Support
1

As stated, I have a bug concerning the $PATH variable. At first, I filed it against Yakuake, but it has everything to do with the shell, hence a post here.

Bug report : 428553 – Yakuake's path searching algorithm has issues
Summary : (I use opam, the OCaml package manager, but it has nothing special; any executable which can display two different versions should behave similarly)

$ opam --version  # Current version of opam
2.0.7
$ sudo cp /home/me/.opam/common/lib/opam-devel/opam /usr/local/bin  # Copy a beta version (2.1.0~beta3) to its advised location, in $PATH
$ opam --version  # Didn't register the new executable
2.0.7
$ which opam   # Correctly searches in $PATH
/usr/local/bin/opam
$ /usr/local/bin/opam --version  # The new executable
2.1.0~beta3
$ which opam -a                
/usr/local/bin/opam
/usr/bin/opam
$ /usr/bin/opam --version  # The older version, still chosen by Yakuake
2.0.7
$ echo $PATH
[local paths]:/usr/local/sbin:/usr/local/bin:/usr/bin:[more global paths]
$ sudo mv /usr/bin/opam /tmp/me/opam
$ opam --version
bash: /usr/bin/opam: [No such file or folder / in French]
$ which opam -a
/usr/local/bin/opam
2

I suspect this is because the current shell only knows of the latter because you have requested it.

If you close the shell and reopen it - your shell should pick the one you copied to /usr/local.

I have tried the same thing with scripts I copied from /usr/bin to .local/bin - if had searched for it using which - then the open shell would not register the new location.

Close/Reopen - usually do the trick.

I don’t know if the behavior can be changed by setting the shell as login shell.

3

I don’t know what you mean by “requested”. I also observed the fact that other shells got the right executable (see second comment in the bug report).

5

Sorry but I still don’t understand your interpretation.
Would it be caused by the fact that bash has in a way stored the location of opam at the first call, and then never tried to update this location (my current interpretation), or would which have an influence over this issue?

6

What happens if you close and reopen the terminal after this step?

7

Yes, that could happen. Run type opam, I think you’ll see something like "opam is hashed (/usr/bin/opam)". Run hash -r opam to clear the cache entry for opam and try again.

8

I guess closing and reopening would do the same, but I tried with opening a new tab, and this causes the intended behaviour to happen (opam --version yields 2.1.0~beta3)

9

This is it !
I had this (the status of beta and non-beta are reversed, because I did install the beta and removed it for the test) :

$ opam --version
2.1.0~beta3
$ which opam
/usr/local/bin/opam
$ sudo rm /usr/local/bin/opam 
$ opam --version
bash: /usr/local/bin/opam: [No file]
$ type opam
opam [is hashed] (/usr/local/bin/opam)
$ hash -r
$ type opam
opam [is] /usr/bin/opam
$ opam --version
2.0.7

Thanks @pobrn

10

That is exactly what I mean - if you run which to find a binary in the search path - the result is cached - and you have close that specific shell - and reopen to force it to find the new location.

11

The fact that which displayed the correct (unhashed) results but executing the binary didn’t leads me to think that the hashing table is only used and updated by direct calls to the binary, not by which.

12

Two ways of achieving the same result.

I have never cared to look for the a deeper cause - open/close terminal works. For me it is AltF4 then SuperEnter which to me is faster than hash -r binary :grin:

13

I mostly wanted to make sure this was intended in some way.
Also, I think hash -r is enough, so it may be quicker, and less annoying regarding the history of the last commands (I mean, clearing the screen can be annoying, so quit/restart can be annoying)

14

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.