Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 154280 - fails to run external commands
Summary: fails to run external commands
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
 
Reported: 2005-04-08 23:26 UTC by David Bentley
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 2.6.0.8-9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-05 00:57:50 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description David Bentley 2005-04-08 23:26:01 UTC 
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.
Comment 1 David Bentley 2005-04-09 20:27:11 UTC 
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.
Comment 2 David Bentley 2005-04-15 23:14:48 UTC 
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 16:53:29 UTC 
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.
Comment 4 Bill Nottingham 2005-04-19 17:07:29 UTC 
Does this persist for both logins on the console and in X?
Comment 5 David Bentley 2005-04-20 13:19:13 UTC 
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 15:58:40 UTC 
What happens if you boot in text mode (add '3' to the command line in grub)?
Comment 7 David Bentley 2005-04-20 20:34:47 UTC 
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 20:39:28 UTC 
oops a typo /usl/local/bin should have been /usr/local/bin in comment #7 above.
Comment 9 Bill Nottingham 2005-04-20 20:46:27 UTC 
gdm appears to be overriding the path somehow. Assigning there.
Comment 10 Ray Strode [halfline] 2005-04-20 21:11:15 UTC 
Yup,
This is my fault.  I'll fix it.
Comment 11 Ray Strode [halfline] 2005-04-26 14:51:00 UTC 
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?
Comment 12 David Bentley 2005-04-27 21:16:12 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.