I'm using screen (the problematically named terminal session manager) on a remote system accessed over SSH - to run long running processes and such. I have eventually started using a command to attach directly to the screen session, instead of first logging in through SSH and then start screen:

ssh -t hostname screen -xRR

The use of the -xRR is to attach to the existing screen session, if available, otherwise just create a new one. The problem is that when a new session is created, it is not created as a login shell:

$ shopt -q login_shell; echo $?

and as a result, login session setup (running .profile and friends) isn't done and then parts of the setup is missing, compared to first using SSH to login and then running screen - in which case the shell SSH starts is a login shell and it is setup properly and screen I guess inherits the environment.

I tried using the -l flag on screen, which is documented as "Login mode", but it doesn't help - I think it only updates the "login time" for things like who.

Any idea how to get screen to run a login shell?

  • 7
    I normally refer to it as "GNU Screen" or similar to try to make it unambiguous. Commented Jul 18, 2023 at 19:01

1 Answer 1


From the man pages of GNU screen:

-s program

sets the default shell to the program specified, instead of the value in the environment variable $SHELL (or "/bin/sh" if not defined). This can also be defined through the "shell" .screenrc command.


shell command

Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL. This is useful if you’d like to run a tty-enhancer which is expecting to execute the program specified in $SHELL. If the command begins with a ‘-’ character, the shell will be started as a login-shell. Typical shells do only minimal initialization when not started as a login-shell. E.g. Bash will not read your ~/.bashrc unless it is a login-shell.

defshell is currently a synonym to the shell .screenrc command.

So you have two options:

  1. Run the following command to ensure that bash is launched as a login shell:

    ssh -t hostname screen -xRR -s -bash
  2. If you want this behavior to be the default one, add the following line to your $HOME/.screenrc file on the destination host (or wherever you run your screen command):

    shell -bash
  • 1
    I've noticed the shell command, but didn't find how to invoke it from the command line, so - thank you. It looks to be working well - in that the shell is now a login shell, but now for some reason, in the login shell, ANSI character graphics (like used in mc or htop) show as "�" (the unicode decode failure glyph). I can fix this by adding -U, but this only happens with -s -bash, while when setting -s bash it's not a problem - what gives?
    – Guss
    Commented Jul 18, 2023 at 12:25
  • 1
    Apparently the problem is that with a non-login shell, screen uses the locale environment variables passed from the local shell though SSH. My local locale is en_IL.UTF-8 while the default login shell locale inside screen is C.UTF-8. How would that cause this unicode decoding issue is beyond me, but I can workaround the problem by setting LC_NAME=en_IL in the ~/.profile file.
    – Guss
    Commented Jul 18, 2023 at 12:34

You must log in to answer this question.

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