2

As stated, having trouble with loading the default profile of <<user_acct>> when doing sudo su -l <<user_acct>>.

Inside .profile,

if [ -r "${HOME}/.profile.custom" ]; then
    . "${HOME}/.profile.custom"
fi

From what I've read (for example, answers similar to this one), -l should have triggered a login shell and therefore sourced .profile, but it doesn't seem to be working because the environment variables set in .profile.custom is not there (vs. if I just ran . .profile, they show up.

Revised question: Any thoughts why or how to get around this issue?

Roman Riabenko
  • 2,145
  • 3
  • 15
  • 39
user1766760
  • 525
  • 6
  • 13
  • Are you using Bash? What directory is `.profile` in? Why `~/.profile.custom` instead of just putting the "custom commands" in `~/.profile` (that's what it's there for)? – depquid Mar 29 '13 at 17:33
  • @depquid Yes on Bash... actually I found out that I should be using `.bash_profile` instead to set the additional env variables. `.profile` is under the home directory of the `<>`. As for `.profile.custom`... no particular reason I guess, just that these are custom things so we put it in a custom file (just our team's preference) – user1766760 Mar 29 '13 at 19:05

3 Answers3

2

Don't do sudo su, that's not needed. sudo -i -u loginname is what you want.

Dennis Kaarsemaker
  • 8,420
  • 3
  • 29
  • 31
  • This looks really promising, but unfortunately I am not allowed to run this command on my team. Or rather, our admin didn't want to open up the ability to run `bash` under the `<>`... Not really seeing why we shouldn't open up the permission if we already have `sudo su` but out of my control *shrug* – user1766760 Mar 29 '13 at 19:01
  • Yeah, you are running Bash as "`<>`"; that's why it's called `.bash_profile`. – depquid Mar 31 '13 at 02:30
2

When it's a login shell, bash first looks for ~/.bash_profile. If it doesn't find it, it looks for ~/.bash_login. If it doesn't find it, it looks for ~/.profile. In any case, even if the login shell is interactive, bash doesn't read ~/.bashrc.

I recommend to stick to the following content in ~/.bash_profile, and to not have a ~/.bash_login:

if [ -e ~/.profile ]; then . ~/.profile; fi
case $- in *i*) if [ -e ~/.bashrc ]; then . ~/.bashrc; fi;; esac

That way your .profile is loaded whether your login shell is bash or some other sh variant, and your .bashrc is loaded by bash whether the shell is a login shell or not.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • I can definitely see a benefit to setting up an OS-agnostic profile. I'm going to mark your answer as accepted since there are learning points that I think could benefit others. Cheers! – user1766760 Apr 02 '13 at 18:17
0

The author of the question provided the following solution:

I found a solution for my problem after all... Turns out it was rather trivial - just set the environment variables in .bash_profile instead and they are set.

According to the bash man page, as discussed here,

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

.. the key lies in the first one that exists.

Lesson learned: read the "fine" print

Roman Riabenko
  • 2,145
  • 3
  • 15
  • 39