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: Always 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.
After further investigation it seems that /usr/local/bin is missing from the PATH. echo $PATH produces the following when loged in as root. /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/root/bin and on my CORE3 machine it produces /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/root/bin 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.
Yup, This is my fault. I'll fix it.
Hi David, This should be fixed in gdm-2.6.0.8-9 in tomorrow's rawhide. Can you test it and report back whether it fixes your problem or not?
Todays update actually delivered gdm-2.6.0.8-10 and the path problem is indeed fixed. But I now no-longer have the option to shutdown but just logout and restart.