Tony Heal wrote:
I have a problem on one of my servers. The ‘ls’ command does not have the –h switch available. So as a workaround until I can determine what caused this and why I wanted to use the ‘ls’ file from another server. I copied /bin/ls from server # 2 onto server # 1 and tested it and it works fine, including the –h switch.So I typed set, read the PATH and found that /usr/local/bin is in the path before /usr/bin. I thought I could simply drop the new ls in /usr/local/bin and the system would see it first when called and use it. WRONG.So my questions are: 1. why not? 2. what is the order used in the path?ThanksTony
Depends on what you mean by 'system'. Do you mean system rc scripts, cron jobs or other 'system' invoked jobs? Or do you just mean for logins on that 'system'?
In the first case, 'system' scripts often explicitly set the PATH value, as a security measure, to a limited list of directories that *does not* include /usr/local/*. The simplest fix for this is to move the original 'ls' to 'ls.no-h' (or some such) and copy the replacement in its place.
In the second case, if you want any and all users to see the replacement in /usr/local/bin, you can edit the shell startup scripts in /etc (bash.bashrc, profile, csh.login, depending on your shell usage) and put /usr/local/bin first in the default. Note that this can be modified by the user in their own startup file, resulting in not getting the right 'ls' command. So, I'd suggest doing the same thing in this case as above, thus assuring there's only one 'ls' to find.
Bob
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature