Bug 164487 - Desktop shortcuts do not respect PATH
Summary: Desktop shortcuts do not respect PATH
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdesktop
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords: needs_verification
Depends on:
Blocks:
 
Reported: 2008-06-20 01:35 UTC by Unknown
Modified: 2018-09-04 20:02 UTC (History)
1 user (show)

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 Unknown 2008-06-20 01:35:55 UTC
Version:            (using KDE 3.5.8)
Installed from:    Ubuntu Packages
OS:                Linux

When I create a Desktop shortcut that has its "Command" set to "firefox" then /usr/bin/firefox, even though PATH=/usr/local/bin:/usr/bin and entering "firefox" on the commandline (bash) starts /usr/local/bin/firefox.

A desktop shortcut (*.desktop file) with Exec=[command] should execute exactly the same file as when I issue "[command]" in a shell.

In particular, I expect KDE to respect my PATH environment variable, i.e. if PATH=/usr/local/bin:/usr/bin and there are executable files /usr/local/bin/firefox and /usr/bin/firefox, then a Desktop shortcut with the command set to "firefox" should execute "/usr/local/bin/firefox" and _not_ "/usr/bin/firefox".
Comment 1 Unknown 2008-06-20 01:39:06 UTC
Sorry, I missed part of the first sentence, it should read: 

When I create a Desktop shortcut that has its "Command" set to "firefox" then /usr/bin/firefox gets executed when I click the shortcut, even though PATH=/usr/local/bin:/usr/bin and entering "firefox" on the commandline (bash) starts /usr/local/bin/firefox. 
Comment 2 FiNeX 2008-12-10 13:53:35 UTC
Is this reproducible on KDE 4?
Comment 3 FiNeX 2009-09-18 13:58:00 UTC
waiting for info
Comment 4 Andrew Crouthamel 2018-09-04 20:02:11 UTC
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I will be closing this bug.