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"

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?

Update 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

  • 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 <<user_acct>>. 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
  • You should put the solution in an answer and accept that, rather than editing the question. – depquid Mar 29 '13 at 19:22
  • @depquid Yes I will, but not allowed to until 5 more hrs :( No privilege. – user1766760 Mar 29 '13 at 19:25

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.

  • 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 2 '13 at 18:17

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

  • 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 <<user_acct>>... 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 "<<user_acct>>"; that's why it's called .bash_profile. – depquid Mar 31 '13 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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