I want to be able to run sudo -s as a user with sudo priv, and have /root/.bashrc be sourced. I checked the .bashrc file and the .profile file for /root, both look fine.

Every time I try to use sudo -s as a user, .bashrc is never sourced. When running sudo -i, .bashrc is sourced.

Why is .bashrc not sourced with sudo -s but is sourced with sudo -i?

I did not change anything in /root/.bashrc or /root/.profile after deployment that I know of.


# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc

mesg n 2> /dev/null || true


# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
# ... or force ignoredups and ignorespace

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
#    . /etc/bash_completion


I figured out the problem. First of all, the .bashrc file was being sourced the whole time, I just thought it was not because there was no color being applied to the terminal session. To add color to work again I needed to adjust a section in the .bashrc file that was causing problems.

Problem section

    xterm-color) color_prompt=yes;;

Change to the following

    xterm-color|*-256color) color_prompt=yes;;
  • 2
    What is the $SHELL variable set to as the user you are running sudo -s from? Is it possible that it is set to something other than /bin/bash? If so, then the interactive shell being started as root will be the same as whatever $SHELL was set to.
    – Natolio
    Dec 14, 2021 at 16:16
  • How are you checking if /root/.bashrc is being sourced? If you add something like echo "bashrc is being read!" into /root/.bashrc and then run sudo -s do you see the line printed? Also, what operating system are you using and what is your default shell? What's is the output of echo $SHELL as Natolio asked?
    – terdon
    Dec 14, 2021 at 20:14

1 Answer 1


sudo -s when run without a command (sudo -s ls for instance) starts an interactive shell. sudo -i starts a login shell which sources all of the standard login shell rc files—.profile, .bash_login.

So everything is working as it should. I frequently use sudo -s because I don’t want to change my current directory to the root user’s home.

However if you don't want to use sudo -i then sudo -s bash -l should work. bash -l starts a login shell.

  • Ok, then why do I not see this behavior with my other hosts? I am basing this off the color of the text that appears for the cursor when running sudo -s, All my other hosts seem to source .bashrc just fine when running sudo -s.
    – Dave
    Dec 14, 2021 at 19:29
  • I'm not sure. Is there any reason you don't want to use sudo -i?
    – meangrape
    Dec 14, 2021 at 20:05
  • 1
    Thanks for the edit! I also removed the incorrect claim about login shells sourcing bashrc (that only happens if ~/.profile is set to source ~/.bashrc as is the case in the OP's example and in some Linux distributions). Thing is, sudo -s should read .bashrc since it is an interactive non-login shell. So something is weird here.
    – terdon
    Dec 14, 2021 at 20:12

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.