Bug 154280 - fails to run external commands
fails to run external commands
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Mike McLean
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
Reported: 2005-04-08 19:26 EDT by David Bentley
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-04 20:57:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Bentley 2005-04-08 19:26:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.2-3

Description of problem:
I have rar and unrar correctly installed on my system and recently noticed that I can nolonger run either program from a terminal window without the full path.

ie instead of typing rar you now have to type /usr/local/bin/rar

I know this did work OK at some point when I installed rar and unrar using the supplied make file because I tested it after I installed it.

I also notice that fileroller can now nolonger open .rar files (it shells out to rar or unrar if it theyare installed or atleast it did when I originally installed rar and unrar.)

Version-Release number of selected component (if applicable):
GNU bash, version 3.00.16(1)-release (i386-redhat-linux-gnu)

How reproducible:

Steps to Reproduce:
type rar at the prompt

Actual Results:  bash: rar: command not found

Expected Results:  the usual rar help screen

Additional info:

I know that FC4test2 is due on the 11th of April and expect it also to exhibit this problem.

When I do a fresh install ASAP after FC4test2 is released I will either close this or bump it to FC4test2 depending on what I find after re-installing and testing rar, unrar and fileroller.
Comment 1 David Bentley 2005-04-09 16:27:11 EDT
After further investigation it seems that /usr/local/bin is missing from the PATH.

echo $PATH produces the following when loged in as root.


and on my CORE3 machine it produces


I have found out how the kerberos, X11R6 and root bits get added to the path 
(when /etc/profile gets processed) and can only assume that /usr/local/bin is
hard coded into bash.

I havent looked at the latest source yet (30th of March) to see if I can spot
where the problem is but I am shure all was Ok prior to this latest update.
Comment 2 David Bentley 2005-04-15 19:14:48 EDT
Having now installed fc4tes2 the problem is still aparent as descibed erlier so
I am now altering the report to show it against fc4test2.
Comment 3 Tim Waugh 2005-04-19 12:53:29 EDT
Whatever problem this is, it isn't to do with bash.  /usr/local/bin is still

Changing component to setup, which owns the /etc/profile file.
Comment 4 Bill Nottingham 2005-04-19 13:07:29 EDT
Does this persist for both logins on the console and in X?
Comment 5 David Bentley 2005-04-20 09:19:13 EDT
Can't tell as my test system uses a matrox g400 graphics card and is suffering
from bug 153729.
Comment 6 Bill Nottingham 2005-04-20 11:58:40 EDT
What happens if you boot in text mode (add '3' to the command line in grub)?
Comment 7 David Bentley 2005-04-20 16:34:47 EDT
If I boot into run level 3 as suggested then as either root or a normal user
/usl/local/bin is in the PATH and if at this run level I go to graphical mode
(startx) then (starting as root) all is still OK in a terminal window but on
loging out I end up at the blank green bordered screen stage where I can blindly
execute the appropriate commands to become a normal user and again enter graphical
mode and all is OK in the terminal as I expected.

So all is OK at run level 3 but not when rebooted and again back in run level 5
Comment 8 David Bentley 2005-04-20 16:39:28 EDT
oops a typo /usl/local/bin should have been /usr/local/bin in comment #7 above.
Comment 9 Bill Nottingham 2005-04-20 16:46:27 EDT
gdm appears to be overriding the path somehow. Assigning there.
Comment 10 Ray Strode [halfline] 2005-04-20 17:11:15 EDT
This is my fault.  I'll fix it.
Comment 11 Ray Strode [halfline] 2005-04-26 10:51:00 EDT
Hi David,

This should be fixed in gdm- in tomorrow's rawhide.  Can you test it
and report back whether it fixes your problem or not?
Comment 12 David Bentley 2005-04-27 17:16:12 EDT
Todays update actually delivered gdm- and the path problem is indeed

But I now no-longer have the option to shutdown but just logout and restart.

Note You need to log in before you can comment on or make changes to this bug.