Just learned about the screen command on linux - it is genius. I love it. However, the actual terminal/prompt in screen looks and behaves differently than my standard bash prompt. That is, the colors aren't the same, tab completion doesn't seem to work, etc.

Is there a way I can tell screen to behave just like a normal (at least, normal as in what I am used to) bash prompt ?

Additional Information

I am connecting via ssh from a Mac (Terminal) to a headless linux box (Ubuntu). After logging in, I have TERM=xterm-color and when I run screen I have TERM=screen.

Am going to try the suggestions below to see if I can change the $TERM value first.

  • Just out of curiosity what OS, and what type of terminal do you have when start screen? I would guess your issues has more to do with your Terminal doing something wrong or identifying incorrectly to screen.
    – Zoredache
    Commented Mar 24, 2010 at 23:30
  • @Zoredache - I added that information to the post, above. Thanks. I did have to adjust my Terminal's settings to allow the backspace key to work ...
    – thornomad
    Commented Mar 26, 2010 at 10:29
  • Yuck, I really don't like Terminal.app. Personally I suggest you consider using an alternative see (serverfault.com/questions/19240/…)
    – Zoredache
    Commented Mar 26, 2010 at 16:54

8 Answers 8


Thanks to this post, what I did was add one line to ~/.screenrc:

# ~/.screenrc
defshell -bash      # dash makes it a login shell

Then things in your ~/.bashrc, /etc/bashrc, etc. should get run.

  • 1
    ^ This is the answer! Worked for me!
    – Andy B
    Commented Aug 6, 2020 at 17:52
  • Note that this will set your $SHELL to bash (no path). You can actually do shell -/bin/bash in your ~/.screenrc which will set $SHELL to /bin/bash -- that works better if a program tries to use execv on the value. (OpenSSH ProxyCommand, I'm looking at you). Also since you can't change this value dynamically, defshell and shell are the same.
    – LHMathies
    Commented Oct 8, 2021 at 12:08

screen changes the term-type to screen. You can do one of two things:

  1. change the term setting in your .screenrc
  2. modify your .bashrc files look for TERM=screen as well as TERM=xterm
  • 4
    Thanks! I created a $HOME/.screenrc file and added this line to the top: term xterm-color and wa la! Color prompt and the $TERM values match. However, no tab-completion ...
    – thornomad
    Commented Mar 26, 2010 at 10:37
  • You need to dig into what turns the tab-completion on. The default shell configuration scripts are not entirely consistent about what they enable based on $TERM; some things will enable with xterm as well as xterm-color, others only look for xterm. Other things have other switches.
    – staticsan
    Commented Mar 29, 2010 at 5:02

I like the way you wrote your question, I was asking myself the same thing and it took a little while to figure it out. I was fortunate to already know a little about shell invocation, so I figured the problem lay there somewhere.

Here are my findings. Firstly, I personally find it interesting and worth knowing the difference between a login shell and a non-login shell. Do a man $SHELL and search for the section on INVOCATION to read more about it.

You can ask your current shell instance if its a login shell or non-login shell by issuing a shopt login_shell on your prompt. Note this is normally a read only option.

On my Debian systems, screen has always come defaulted with non-login shells.

After searching the web and reading man $SHELL, I tested a few things out and the following two approaches worked for me. In ~/.screenrc add/update a line as follows:

shell -$SHELL

If that doesn't work out AND you are using bash, you can alternatively try, as shared by Seamus:

defshell -bash

As mentioned, you can test if your current shell instance is a login shell by issuing shopt login_shell on your prompt.

  • Is the way to have the shell launch in the current directory? An example of what I desire is the following cd ~/Projects ; screen ; pwd #=> ~/Projects. However, what I get after adding shell -$SHELL to my ~/.screenrc is cd ~/Projects ; screen ; pwd #=> ~/
    – rudolph9
    Commented Aug 12, 2017 at 1:27

Depending on how you're used to running Bash, you may be running a login shell. When you run screen, you're running a non-login interactive shell.

The difference is in which startup scripts are run.

  • /etc/bash.bashrc then ~/.bashrc are sourced when a non-login interactive shell is started

  • /etc/profile then the first found of ~/.bash_profile, ~/.bash_login, and ~/.profile are sourced when an interactive login shell is started

This may be affecting you.

I would also check to see if $TERM is different.


screen doesn't replace bash, it runs it, or any other shell. maybe it's running csh, zsh, or bash but with different paramters.

the first thing i would try is to check with ps and /proc/<pid>/cmdline to be sure that it's using the same shell with same parameters as login does.

after that, check /etc/screenrc and any other file mentioned at man screen FILES section.

  • I ran a ps command and it shows that bash is running (this is a ps command inside of screen) ... I got the color working (above) just need tab completion.
    – thornomad
    Commented Mar 26, 2010 at 10:37

I had the same problem, when I ran screen I lost the cool PS1 color prompt I had craftily found :P.

Issue is I was running it like this in ~/.bash_profile

PS1="\[\033[35m\]\t\[\033[m\]-\[\033[36m\]\u\[\033[m\]@\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ "

That means that when screen was running the bash_profile the PS1 is not being carried over.

Fix is easy: add export to the PS1 statement in the ~./bash_profile to look like this :

export PS1="\[\033[35m\]\t\[\033[m\]-\[\033[36m\]\u\[\033[m\]@\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ "

Like that the variable is not lost in the nested execution.


Just want to add something about "defshell -bash" (which I just figured out, after months of head-scratching). When you do that, the child shell run by screen has $SHELL set to "bash", instead of "/bin/bash" like it normally would be. If you then run "script" inside your screen session, you get:

$ script
Script started, file is typescript
script: failed to execute bash: No such file or directory

Or at least that's what happens on my Ubuntu 14.04 box. The workaround I've been using is to run $ SHELL=/bin/bash script. I would imagine having $SHELL set wrong will break other stuff, but script is what I've noticed.


I'm using this snippet in my .profile before any shell initialization is started:

[ "$( which screen 2> /dev/null )" ] && {
    # Uncomment for old screen's (exit codes are lower by one)
    screen -q -ls
    if [ $? -gt ${_old_screen_base:-10} ]; then
        read -p "$(tput setaf 2)Found a running SCREEN sesion, attach?$(tput sgr0)[Y/n] " y >&2
        if [ "${y:-y}" = "y" -o "$y" = "Y" ]; then
            exec screen -aDR
        echo "$(tput setaf 3)No attachable SCREEN sessions found.$(tput sgr0)" >&2

Then, if there's no screen session is running, I… well, I just fall into standard shell prompt. If I plan to perform a lengthy task, I launch screen manually in my user's session and if I get disconnected, I just hop back and say "yes" to attach prompt.

The key point here is "before any shell initialization", so that when you already have a running screen session, it is already initialized with locale and other stuff and you do not need to redo it again.

You must log in to answer this question.

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