Summary: | Given a PATH with /usr/local/bin before /usr/bin, krunner prefers /usr/bin/test.sh instead of /usr/local/bin/test.sh | ||
---|---|---|---|
Product: | [Unmaintained] kio | Reporter: | Daniel Hahler <kde-bugzilla> |
Component: | general | Assignee: | David Faure <faure> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | faure, israel.lugo, jsatt22, markg85, mat69, qmysjwxb8zhc25n, smls75 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 4.8.1 | |
Sentry Crash Report: | |||
Attachments: |
test-program
modified pathtest that reports installPath(exe) and installPath(libexec) |
Description
Daniel Hahler
2010-06-14 21:10:32 UTC
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 |