47

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
  • 571
  • 1
  • 4
  • 5
  • 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 Mar 24 '10 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 Mar 26 '10 at 10:29
  • Yuck, I really don't like Terminal.app. Personally I suggest you consider using an alternative see (http://serverfault.com/questions/19240/poll-what-is-your-favourite-terminal-program) – Zoredache Mar 26 '10 at 16:54

8 Answers8

49

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
  • 683
  • 1
    ^ This is the answer! Worked for me! – Andy B Aug 06 '20 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 Oct 08 '21 at 12:08
14

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,539
  • 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 Mar 26 '10 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 Mar 29 '10 at 05:02
12

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
  • 544
  • 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 Aug 12 '17 at 01:27
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
  • 62,879
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,378
  • 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 Mar 26 '10 at 10:37
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
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
  • 493
  • 1
  • 5
  • 6
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
  • 271