Red Hat Bugzilla – Bug 154280
fails to run external commands
Last modified: 2007-11-30 17:11:03 EST
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)
Steps to Reproduce:
type rar at the prompt
Actual Results: bash: rar: command not found
Expected Results: the usual rar help screen
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.
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.
Having now installed fc4tes2 the problem is still aparent as descibed erlier so
I am now altering the report to show it against fc4test2.
Whatever problem this is, it isn't to do with bash. /usr/local/bin is still
part of DEFAULT_PATH_VALUE.
Changing component to setup, which owns the /etc/profile file.
Does this persist for both logins on the console and in X?
Can't tell as my test system uses a matrox g400 graphics card and is suffering
from bug 153729.
What happens if you boot in text mode (add '3' to the command line in grub)?
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
oops a typo /usl/local/bin should have been /usr/local/bin in comment #7 above.
gdm appears to be overriding the path somehow. Assigning there.
This is my fault. I'll fix it.
This should be fixed in gdm-220.127.116.11-9 in tomorrow's rawhide. Can you test it
and report back whether it fixes your problem or not?
Todays update actually delivered gdm-18.104.22.168-10 and the path problem is indeed
But I now no-longer have the option to shutdown but just logout and restart.