Linux – How to persist `gnu screen` layout after restart

gnu-screenlinux

I am using the screen split in 3 with vim on the left, and two other screens split horizontally on the right. I know that when detaching from a screen, I can save the layout with :layout save my_layout_name.

I already have layout autosave on in my .screenrc file, but that doesn't help with my issue.

How can I persist a screen's layout between different terminal sessions, and after pc restart? Or maybe as a workaround, is there a way to run screen (parameters) which split it, set up the bash on every window and save the layout?

Best Answer

Default layout for new screen's

Manage your regions, then execute code inside screen:

To save your current layout to file .screen_layout:

rm -f $HOME/.screen_layout
screen -X layout dump .screen_layout

To make it auto-loading with layout saving:

echo source .screen_layout  >> $HOME/.screenrc
echo layout save def >> $HOME/.screenrc

How it works

You type screen.
Screen reads $HOME/.screenrc:
source .screen_layout - read and execute commands from $HOME/.screen_layout
Regions now created.
layout save def - save current regions as layout to keep it when you detach.

layout dump .screen_layout

Dump (append) current layout to file in $HOME directory

screen -X command

Run command in current screen session (if executed inside).
Similar to ctrla then : command

You may also

Disable copyright notice at startup:

echo startup_message off >> $HOME/.screenrc

Increase scroll buffer(def. 100)

echo defscrollback 1000 >> $HOME/.screenrc

Write own .screen_layout (50% / 50% vertical, with 2 shells):
```
split -v
screen -t s1

focus
screen -t s2

focus
```

Related Solutions

Linux – GNU/Linux: Dual screen and separate workspaces

So, as implemented in KDE And Gnome, this is beyond "not easy" - it's darn near impossible. Here's why: the virtual workspaces are implemented in widgets that run in the window manager. They're implemented with trickery and magic and bound entirely to one window manager running on one DISPLAY.

The window manager, virtual-workspace-management widgets, and client applications all run on the same DISPLAY (as in the $DISPLAY environment variable; typically :0.0) Your second monitor, in non-twinview-mode, is actually running on a separate DISPLAY - probably :0.1 You can verify this by running 'echo $DISPLAY' from a shell prompt in a terminal program on each monitor.

Each DISPLAY is running its own X-server. So, they have no idea about each other's windows, windowmanagers, or virtual workspaces.

I would bet the various tiling windowmanagers will want you to have your monitor in twinview mode. Then they can carefully work with the real-estate that's in one and in the other, in the same DISPLAY... and fake you into thinking they're two separate "workspaces" (same word but not same meaning as virtual workspaces).

There are numerous X-window issues that would make it quite difficult to move or migrate a running Xwindow client program from one DISPLAY to another seamlessly. Not saying it can't be done; it may have been done... but I'll bet it's buggy or at least limited; I doubt you could move a firefox window playing a video between DISPLAYs, for example.

Hope this helps! -pbr

How to get the F1-F12 keys to switch screens in gnu screen in cygwin when connecting via SSH

With a great deal of experimentation, I was able to get it to work by adding the following lines to my .screenrc:

terminfo * k1=\EOP
terminfo * k2=\EOQ
terminfo * k3=\EOR
terminfo * k4=\EOS
terminfo * k5=\E[15~
terminfo * k6=\E[17~
terminfo * k7=\E[18~
terminfo * k8=\E[19~
terminfo * k9=\E[20~
terminfo * F1=\E[23~
terminfo * F2=\E[24~