Version: unspecified (using Devel) OS: Linux Until recently I've thought that KRunner would ignore /usr/local/bin from my PATH completely, but as it turns out, it just prefers programs in /usr/bin (apparently). Reproducible: Always Steps to Reproduce: 1. Set PATH to e.g. /home/USER/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games (e.g. via /etc/environment), but apparently my ~/.zshrc is used, too (adding the ~/bin part) 2. Add a test.sh file to /usr/local/bin and symlink it into /usr/bin. I have used ("-f" to not use any RCs files): #!/usr/bin/zsh -f echo $0 > /tmp/testsh-path echo $SHELL >> /tmp/testsh-path echo $PATH >> /tmp/testsh-path 3. Run test.sh from krunner (Alt-F2, "test.sh", Enter) Actual Results: /tmp/testsh-path will contain: /usr/bin/test.sh /bin/zsh /home/USER/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games Expected Results: The first line ($0, script name) should be /usr/local/bin/test.sh instead. When removing the symlink from /usr/bin, /usr/local/bin gets used - so it is not ignoring it completely.
Even using the following construct, /usr/bin/test.sh is used: PATH=/usr/local/bin /usr/bin/krunner
Another bug, but very much related: when there's /usr/bin/eclipse and /usr/local/bin/eclipse, the former gets started for "eclipse". However, after purging the eclipse package and removing /usr/bin/eclipse, krunner won't start /u/l/b/eclipse, too! Looks like the result has been cached and the cache does not get dismissed on cache miss.
*** This bug has been marked as a duplicate of bug 203721 ***
Ok, I just tried the method you described. /usr/local/bin/test.sh /bin/bash /home/mat-not/kde/bin:/usr/local/bin:/home/mat-not/kde/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/opt/java/bin:/opt/java/db/bin:/opt/java/jre/bin:/usr/lib/perl5/vendor_perl/bin:/usr/bin/perlbin/vendor:/usr/lib/perl5/core_perl/bin:/opt/qt/bin Is what I get (yeah the path on my devel-account is a little crappy ;) ), I am using bash as shell and here it worked as it should. Could you please retry with trunk -- that is the version I tried -- and see if you still have this problem? If you still have it, could you please retry with bash as default shell?
*** Bug 203721 has been marked as a duplicate of this bug. ***
I am re-opening it: It still happens for me with KDE 4.6b2 (not so easy to try with trunk for me). I have tried it after "chsh -s /bin/bash" and re-login, which resulted in: $0: /usr/bin/test.sh $SHELL: /bin/bash $PATH: /home/daniel/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games Going back to zsh it looks like this: $0: /usr/bin/test.sh $SHELL: /bin/zsh $PATH: /home/daniel/bin:/usr/local/bin:/FROM_ETC_ENVIRONMENT:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games On a shell prompt (zsh) the PATH looks like the following btw: /home/daniel/.dotfiles/bin:/home/daniel/bin:/usr/local/bin:/usr/local/sbin:/home/daniel/bin:/usr/local/bin:/FROM_ETC_ENVIRONMENT:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
Interesting that I don't have that bug. To me this looks like a bug in KRun.
Btw. could you compile a small test-program?
Created attachment 54401 [details] test-program Please run the program in the compressed file and post the output here. If you need instructions on how to compile/run it just ask.
Here is the output: Used PATH: /home/daniel/.dotfiles/bin /home/daniel/bin /usr/local/bin /usr/local/sbin /home/daniel/bin /usr/local/bin /FROM_ETC_ENVIRONMENT /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/bin/X11 /usr/games Prefered exe: /usr/bin/test.sh All test.sh found in path: /usr/local/bin/test.sh /usr/local/bin/test.sh /usr/local/bin/test.sh /usr/bin/test.sh /usr/bin/X11/test.sh
Ok, thx. That did help a lot. @dfaure As it appears the bug is at kstandarddirs.cpp:1380. Not sure why both the "libexec" and the "exe" calls are there anyway. Imo they should be after the system paths. Btw. the reason why I could not reproduce this was that I was running trunk and installPath("exe") then points to the bin-dir of KDE of the local installation (e.g. /home/kde-devel/kde/bin). When using a normal installation it will lead to /usr/bin/test.sh in our example.
SVN commit 1207384 by dfaure: findExe: do not look into the "exe" resource explicitely if KDE is installed into /usr. In that case we know it will be part of the $PATH, and we better honour the ordering of $PATH. I still want to keep the "exe"-lookup when KDE is in a custom prefix, so that it works [better] even if $PATH doesn't have the custom prefix. Kudos to Matthias Fuchs and Daniel Hahler for the complete investigation. BUG: 241763 FIXED-IN: 4.6 M +7 -4 kstandarddirs.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1207384
The implemented solution doesn't work for me. I am using KDE 4.6.5 on Gentoo, and the fix from r1207384 is present on my source. However, I still see the problem. A slightly modified version of pathtest shows why: $ ./pathtest Used PATH: /usr/local/bin /usr/bin /bin /opt/bin /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 /usr/games/bin Prefered exe: /usr/bin/test.sh All test.sh found in path: /usr/local/bin/test.sh /usr/bin/test.sh installPath(libexec): /usr/lib64/kde4/libexec/ installPath(exe): /usr/bin/ My installPath is "/usr/bin/", and the fix in r1207384 is checking (p != QLatin1String("/usr/")). The installation was done as per default behavior and the install path seems quite normal to me. For example: $ which krunner /usr/bin/krunner I would suggest at the very least changing KStandardDirs::findExe() to check if p *begins* with "/usr/", instead of being *equal* to "/usr/". Even better, I would suggest checking the system paths *first*, and only *then* checking the KDE-specific bin directory. As it is now, the bug is still very much there on 4.6.
Created attachment 66264 [details] modified pathtest that reports installPath(exe) and installPath(libexec)
The bug still exists for me in KDE 4.8 RC1 on Arch Linux: Preference of /usr/local/bin over /usr/bin in defined through the PATH variable in /etc/profile, and typing test.sh in a shell (in my case bash, not zsh) indeed runs the correct one. But KDE (both KRunner and the pathtest program from this thread) choose to run /usr/bin/test.sh
*** Bug 242834 has been marked as a duplicate of this bug. ***
Git commit a18253a36aa1d5a77c844ce0e5d5699697e58e2c by David Faure. Committed on 05/01/2012 at 19:36. Pushed by dfaure into branch 'KDE/4.8'. Honour $PATH when looking for executables. The very old idea of not requiring PATH to be set, when compiling KDE into a custom prefix, doesn't make that much sense (we require tons of other env vars anyway), and doesn't allow users to control PATH. FIXED-IN: 4.8.1 M +9 -12 kdecore/kernel/kstandarddirs.cpp http://commits.kde.org/kdelibs/a18253a36aa1d5a77c844ce0e5d5699697e58e2c
(In reply to comment #17) > > Honour $PATH when looking for executables. > > The very old idea of not requiring PATH to be set, when compiling KDE > into a custom prefix, doesn't make that much sense (we require tons > of other env vars anyway), and doesn't allow users to control PATH. > FIXED-IN: 4.8.1 > Thank you for the fix! That sounds like the best possible solution, and is consistent with expected behavior in general on a *nix system.
Git commit d6d81ceb4a176f7c709edb8b5223ad2aaf7269f6 by Sebastian Trueg, on behalf of David Faure. Committed on 05/01/2012 at 19:36. Pushed by trueg into branch 'KDE/4.8'. Honour $PATH when looking for executables. The very old idea of not requiring PATH to be set, when compiling KDE into a custom prefix, doesn't make that much sense (we require tons of other env vars anyway), and doesn't allow users to control PATH. FIXED-IN: 4.8.1 M +9 -12 kdecore/kernel/kstandarddirs.cpp http://commits.kde.org/kdelibs/d6d81ceb4a176f7c709edb8b5223ad2aaf7269f6