Bug 428553 - Yakuake's path searching algorithm has issues
Summary: Yakuake's path searching algorithm has issues
Status: RESOLVED DOWNSTREAM
Alias: None
Product: yakuake
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-01 12:02 UTC by yannl35133
Modified: 2020-11-01 14:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description yannl35133 2020-11-01 12:02:43 UTC
SUMMARY
I don't know exactly why this issue arises, but I can explain how I obtained it.
It results in Yakuake not executing the first match when checking against $PATH, probably because this first match didn't exist at first and Yakuake stores this match.

STEPS TO REPRODUCE (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

SOFTWARE/OS VERSIONS
OS: Manjaro Linux KDE
KDE Plasma Version: 5.20.2
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Yakuake Version: yakuake 20.08.2
Comment 1 yannl35133 2020-11-01 12:08:59 UTC
After a bit of testing :
- if another tab executes "opam --version" before the new version is installed, this other tab also won't notice the change
- if another tab is merely created but doesn't interact with opam before the change, it does notice

and more importantly :
- it affects Konsole similarly

Should I report against them?
Comment 2 yannl35133 2020-11-01 12:13:27 UTC
Wait, this issue also happens in GNOME Terminal.

Is it some sort of intended behaviour of bash that I don't know?
Comment 3 Christoph Feck 2020-11-01 14:26:06 UTC
The terminal emulator is not responsible for launching the binaries from the PATH; that's done by the shell.
Comment 4 yannl35133 2020-11-01 14:28:55 UTC
A question then : Where should I file this bug? bash?
Comment 5 Christoph Feck 2020-11-01 14:35:33 UTC
If the PATH variable is setup correctly, and bash doesn't respect the ordering specified there, it would be a bash bug. If the PATH variable is setup wrongly, you would need to find out which component is responsible for setting it; it could be a distribution issue.

I would recommend asking in a help forum first.
Comment 6 yannl35133 2020-11-01 14:45:46 UTC
I asked for help in the Manjaro Forum here : https://forum.manjaro.org/t/apparent-bug-with-path-in-bash/35076