[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep.sh in /etc/profile
|
From: |
Chris B . Vetter |
|
Subject: |
Re: GNUstep.sh in /etc/profile |
|
Date: |
Thu, 16 May 2002 15:15:13 -0700 |
On Thu, 16 May 2002 23:56:33 +0200
Andreas Hoeschler <ahoesch@smartsoft.de> wrote:
> >> I have the entry
> >> . /opt/GNUstep/System/Makefiles/GNUstep.sh
> >> in /etc/profile and use bash for all users. If I log in as ahoesch the
> >> PATH variable is correctly set according to GNUstep.sh. When I log in
> >> as root, it works as well. However, if I log in as ahoesch and then su
> >> to root, the PATH variable does not get set and I have to manually
> >> call ". /opt/GNUstep/System/Makefiles/GNUstep.sh". Why is this the
> >> case? This is on Solaris 8. How can this be fixed?
> > try using "su -" instead of just "su". Then the login scripts will be
> > run as well.
> Yes, but this also changes the current directory which is very annoying.
> I have
> export PATH=$PATH:/usr/local/bin
> in /etc/bashrc and in /etc/profle. However, if I su to root
> /usr/local/bin is still missing in the path. If I login as root
> everything is fine. If I do su - everything is fine as well. Only "su"
> does not reasonably work for me.
su - [username] ... changes the current user to the specified user (or
to root if omitted) - staring a new login shell. It does not change
your current path, it regards the user's login as a completely new
login, therefor you end up in user's home.
su [username] ... changes the current user to the specified user (or
root if omitted) - but does NOT start a new login shell. That means,
neither /etc/* nor $HOME/* login scripts will be executed, as this
"new" user will inherit the previous user's environment, except for
$USER, $HOME and $SHELL.
Check the options for su(1) on your system. Option -m (on mine) may
be what you are looking for:
-m Leave the environment unmodified. The invoked shell is your
login shell, and no directory changes are made. As a security
precaution, if the target user's shell is a non-standard shell
(as defined by getusershell(3)) and the caller's real uid is
non-zero, su will fail.
--
Chris