3

By launching GNU screen or tmux as the initial default shell (set with chsh, for instance), passing arguments seems not to be supported, such as "-d RR" for screen and "attach" for tmux. chsh's argument is the full pathname to a shell file executable (listed in /etc/shells).

For screen, is there an internal command to reattach itself to a previous screen session? Or is there a way to pull the individual processes from the previous screen session into the current session?

For tmux, is there a way to set, in the user configuration file (~/.tmux.conf by default), an option to go directly to the previous session?

After launching tmux without any arguments (which creates a new session), one can manually switch to the previous session (CTRL+B, () and then kill the newly launched session (CTRL+B, :kill-session -a).

muru
  • 72,889
Pedro Palhoto
  • 629
  • 1
  • 6
  • 12

2 Answers2

2

Nice idea. I'd create a wrapper, say /bin/my-screen that would look like this:

#!/usr/bin/env sh

screen -d -RR

Make it executable and add it to /etc/shells:

echo /bin/my-screen | sudo tee -a /etc/shells

Make it the default shell:

chsh --shell /bin/my-screen

Notice that some terminal emulators such as xterm do not run shell defined in /etc/passwd by default but they check $SHELL variable first.

You can try adding this to your ~/.screenrc:

screen -X screen -d -RR

Notice however that there is a potential problem with that solution - you won't be able to start screen at all if there are no existing sessions screen could re-attach. That means that if you set your screen as your default shell you won't be able to log into your system.

Arkadiusz Drabczyk
  • 25,539
0

I have this at the bottom of my zshrc:

[ -z "$TMUX" ] && {
    tmux attach || tmux new-session
}

Haven't had any trouble so far; been there for years on thar particular server I think

  • This mechanism works well for when you start your login with a regular shell. Still looking for a way to do so when screen or tmux are launched directly as the login shell (configured in /etc/shells). – Pedro Palhoto Aug 19 '19 at 17:46
  • What's the difference, functionally, between what I did and directly launching it as the login shell? (Even if you managed it, I think it would cripple things like rsync, scp, etc., and restrict you to interactive logins only. This is of course just a guess). –  Aug 19 '19 at 23:35
  • For the current use case, crippled protocols are not an issue. The objective was to reduce the number of launched processes to a minimum (there is a FG/BG process quota per user). I find it curious there isn't a configurable way (that I could find about so far) that could attach the previous multiterm session after the screen/tmux session has been launched without command line arguments. Perhaps screen/tmux authors never considered the possibility of command line arguments being unavailable. Knowing how to do so could be useful for some other use case besides the one I stumbled upon. – Pedro Palhoto Aug 20 '19 at 07:34
  • I'm pretty sure you can replace "tmux" in my suggestion with "exec tmux" and that will achieve what you want. As for the latter part of your comment, while I can't speak for tmux/screen authors, I have to say your constraints appear to be somewhat unusual so I am not at all surprised. –  Aug 23 '19 at 12:19