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.customfiFrom 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?UpdateI 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
Linux (RedHat) `sudo su -l <>` does not source profile
linux;rhel;sudo;profile
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; ficase $- in *i*) if [ -e ~/.bashrc ]; then . ~/.bashrc; fi;; esacThat 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.