If you're using the Bash shell, when you start a login shell, it sources a file called [tt]/etc/profile[/tt], and then it sources a file in your home directory (if it exists), which can be called either [tt].profile[/tt], [tt].bash_profile[/tt], or [tt].bash_login[/tt].
Thesse are usually used to set up environment variables and other values that will be exported to any other processes (including shells) you start, and thus only need to be set once, when you first log in.
When you start a non-login shell, it reads a file in your home directory called [tt].bashrc[/tt].
This is normally used to set up aliases and other values that
don't get exported, and thus need to get set for each shell instance you use.
Now, in practice, there's really no reason that a login shell shouldn't have aliases set when they do get set for other shells. So usually, users put something like the following in their [tt]~/.profile[/tt]:
Code:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
This causes aliases to be set for login shells as well as for non-login shells.
If a user removed this line from their [tt]~/.profile[/tt], then their login shell might exhibit different behavior than other shells they start.
As far as [tt]su[/tt] is concerned, if you do
then you get a login shell, but if you do
then you get a non-login shell. This carries the same implications for startup shells as mentioned above.
That might get you started on tracking down the problem.
An additional factoid: there's usually an [tt]/etc/bashrc[/tt] file that, while not an "official" startup file, is useful as a non-login analogue to [tt]/etc/profile[/tt]. It normally gets sourced by a user's default [tt]~/.bashrc[/tt] file. Again, a user may have changed this.