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
    Commented 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
    Commented 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
    Commented Dec 14, 2021 at 19:29
  • I'm not sure. Is there any reason you don't want to use sudo -i?
    – meangrape
    Commented 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
    Commented Dec 14, 2021 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .