51

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.

Community
  • 1
thornomad
  • 611
  • 1
  • 6
  • 5

8 Answers8

55

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.

Seamus Abshere
  • 743
16

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
staticsan
  • 1,589
13

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.

Community
  • 1
Kyle
  • 584
10

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.

Dennis Williamson
  • 64,083
3

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.

Javier
  • 9,486
2

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.

davidsaliba
  • 21
  • 1
2

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.

Roy Smith
  • 513
1

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)
    #_old_screen_base=9
    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
        fi
    else
        echo "$(tput setaf 3)No attachable SCREEN sessions found.$(tput sgr0)" >&2
    fi
}

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.

AnrDaemon
  • 301