44

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
  • 541
  • 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

47

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
  • 663
  • 1
  • 6
  • 10
  • 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,529
  • 1
  • 11
  • 14
  • 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
  • 494
  • 1
  • 5
  • 13
  • 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
9

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
  • 60,515
  • 14
  • 113
  • 148
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,078
  • 2
  • 23
  • 24
  • 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
  • 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
  • 483
  • 1
  • 4
  • 6
0

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.

AnrDaemon
  • 131
  • 1
  • 6