Home / server / Questions / 126009
In Process
thornomad
Asked: 2010-03-25 14:24:22 +0800 CST

How do I ask screen to behave like a standard bash shell?

  • 772

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.

bash gnu-screen xterm

8 Answers

  1. 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.

    • 47

  2. 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
    • 14

  3. 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.

    • 12

  4. 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.

    • 9

  5. 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.

    • 3

  6. 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.

    • 2

  7. 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.

    • 2

  8. I'm using this snippet in my .profile before any shell initialization is started: which screen > /dev/null 2>&1 && { screen -q -ls if [ $? -gt 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 screen -aDR && logout fi else echo "$(tput setaf 3)No running SCREEN sessions found.$(tput sgr0)" >&2 fi }

    Then, if there's no screen session is running, I… well, I don't fall into standard shell prompt. There's one more prompt for sudo pasword (since 99% of the time I log in to administer the server), and if I plan to perform a lengthy task, I cancel sudo login, launch screen manually in my user's session and sudo in there.

    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.

    • 0