Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

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

share|improve this question
    
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
add comment

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
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
add comment

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

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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