Red Hat Bugzilla – Full Text Bug Listing
|Summary:||tcsh fails to access executables in /usr/local/bin|
|Product:||[Retired] Red Hat Linux||Reporter:||Kurt Zingler <k_zingler>|
|Component:||tcsh||Assignee:||Eido Inoue <havill>|
|Status:||CLOSED WORKSFORME||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-04-09 11:15:22 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kurt Zingler 2001-04-09 11:15:19 EDT
On both Fisher and Wolverine I am unable to launch executables placed in /usr/local/bin. I can launch them using the full path (e.g. /usr/local/bin/my_executable), but not without that. I can also switch to other shells (e.g. bash) and then "my_executable" will launch from anywhere. /usr/local/bin is a part of my path, which I can clearly see by running env. This is on PII and PIII machines.
Comment 1 Eido Inoue 2001-04-09 11:45:06 EDT
I can't reproduce this with wolverine... I'm accessing /usr/local/bin just fine. Can you give me more details on how to reproduce this or narrow the cases where it fails or succeeds? is /usr/local/bin a NFS mount etc?
Comment 2 Kurt Zingler 2001-04-09 14:55:55 EDT
I have only used this with local ext2 filesystems. I'm at work right now and cannot access my home (wolverine machine). My work machine (Fisher) is running tcsh version tcsh-6.10-2. I can create an excecutable in /bin or /usr/bin and I can launch that exe directly (no path). If I place that same exe in /usr/local/bin, I cannot access it normally, but it works fine with the full path. I can also switch to bash, and execute the file. My path is as defined by the Redhat defaults PATH=/usr/local/bin:/bin:/usr/bin:/usrX11R6/bin If I open new gnome terminal, I can now use the exe. I can also use the exe changing myself to the root user. It appears that the active terminal does not recognize the exe in /usr/local/bin, but it does recognize new exe's in /usr/bin and /bin. I have to open a new window or change shells to find the new file. This is much less of a problem than I previously assumed.