up vote 1 down vote favorite
share [g+] share [fb]

I logged on to my linux server (Redhat AS4) through ssh as the user 'guest', then run the command "echo $PATH", and the output is "/usr/local/bin:/bin:/usr/bin".

However, when I run the command "su - guest" to switch to the same user, then run the command "echo $PATH", the output becomes "/usr/bin:/bin:/usr/local/bin".

Why the same user has different PATH value on linux server? That makes me get different python version and I don't know what causes this problem:(

Any help is appreciate, thanks in advance!

link|improve this question
Merged with migrated question from SO to preserve all answers. – Kara Marfia Sep 1 '09 at 12:35
feedback

5 Answers

up vote 1 down vote accepted

Try to debug using the technique described in my answer on superuser, using

debug_msg "running ~/.bashrc ($0), PATH = '$PATH'"

and similar for /etc/bashrc, /etc/profile, etc.

link|improve this answer
Thanks for you answer:) With the function, I found that the PATH's value is already different at the begining of /etc/profile. I can't found where the PATH is set before the /etc/profile script. Could you give me some advice? Thanks. – bluesea007 Sep 2 '09 at 6:22
1  
Try "find /etc -type f -print0 | xargs -0 grep -l -w PATH" to find potential candidates. – hlovdal Sep 2 '09 at 15:20
Thanks a lot~~ It's really useful! – bluesea007 Sep 3 '09 at 0:59
feedback
up vote 1 down vote

Check the fields ENV_SUPATH and ENV_PATH in /etc/login.def

For good scripting practice, do not rely on the PATH variable to execute a command as it is ambiguous.

link|improve this answer
feedback
up vote 1 down vote

Different scripts (doing different manipulation on the PATH) are sourced in the two cases.
Since you are using the - option, su should source your login script, while ssh should not.

I don't know which behavior you want exactly, but maybe you could check if some su options (e.g. -m, --preserve-environment: do not reset environment variables) could help?

link|improve this answer
Thanks a lot :) After ssh to the server, I can get a beautiful look of the terminal text, but when I use "su - thesameuser", the color of text is gone. I want to know whick scripts cause the difference. Can you give me any advice on that? Thanks. – bluesea007 Sep 1 '09 at 10:12
Use the env command. It's prohably $LS_COLORS, if not, some other environment variable. Why not just ssh to localhost instead of using su? – reinierpost Sep 1 '09 at 11:42
feedback
up vote 1 down vote

It goees like this:-

In /etc/passwd where the user id is defined a home directory and a default shell:

auser:!:97:51::/home/user:/usr/bin/ksh

When auser logs in the 'ksh' or bash or whatever will run this will pick up a default 'PATH' from the '/etc/environment' file (and some shells will run a system wide initialisation file), but, it will also run the commands from an initial script in the home directory in the above case the '.kshrc' file.

So the PATH can be set by the initial command, the system wide settings for that initial command and the 'hidden' .rc files in the users home directory.

The 'su -' does not run the same set of initial commands as login only picks up the default settings from the '/etc/environment' file.

link|improve this answer
feedback
up vote 0 down vote

from su manpage

su is used to become another user during a login session. Invoked with-
       out a username, su defaults to becoming the super  user.  The  optional
       argument  -  may be used to provide an environment similiar to what the
       user would expect had the user logged in directly.

therefore you will always get different env settings on "su" and "su -"

link|improve this answer
1  
The difference are beetween an ssh session and a "su -", not "su" and "su -". – Benoit Sep 1 '09 at 10:36
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.