Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Is it possible to persist the "state" of a GNU screen window (or just a standard shell) so that I can reload everything after a reboot:

  • The number of opened shells
  • The name of each shell
  • The current directory of each shell
  • The history of each shell
  • If possible, their environment variables
share|improve this question
add comment

4 Answers

up vote 9 down vote accepted

It is not really possible to save a complete screen session.

What you can do is to create a proper .screenrc which will setup some things after you restarted your system.

Here are some comments to the things you listed:

  • The number of opened shells
  • The name of each shell
  • The current directory of each shell

I use something like this in my .screenrc to open some specific shells on startup:

## set the default shell
shell                   zsh

# screens
screen -t 'zsh'
screen -t 'mutt' mutt
screen -t 'zsh' /home/user/bin/scriptToRun
[..]

You will get the string between '' as your window name and the command after the name will be executed on your default shell. Include any script you want, for example change in a specific directory and open some logs.

  • The history of each shell

Have you ever thought about sharing the history of the shells across your sessions? IMHO this makes things much more easier. In ZSH its done with setopt SHARE_HISTORY in your .zshrc

  • If possible, their environment variables

If you really need this and don't want any trade-off you could think about a shell script, which reads out the current state of screen, saves the number of shells, environment variables, etc. and puts this information in a startup script called by your .screenrc. For me this would not be worth the effort because I appreciate a clean environment after a reboot, if I can customize the default windows for screen.

share|improve this answer
    
Thanks for your suggestions. I found a way to share my history on bash (not as straightforward as with zsh) so I have one stream of commands that is persisted. Regarding the .screenrc, I should have thought about it. Unfortunately, it seems you can only execute certain scripts (commands like 'cd' don't work), but that should be fine. I don't mind the environment variables if I can initialize a shell with a script. –  Barthelemy Oct 13 '10 at 17:05
    
cd is a built-in function of your shell, a cd command wouldn't make sense outside a "shell" :-) But you can simply include a script which contains a cd /foo/bar after the shebang. Then your new shell will change to this directory. –  echox Oct 14 '10 at 8:35
    
yes I understand this distinction, I just thought that the commands were somehow passed to the shell and then executed in the shell. But I have no problem writing initialization scripts :-) The shared history was a terrific idea btw, I really like it. –  Barthelemy Oct 14 '10 at 9:05
add comment

There is a tool to freeze the state of a process called cryopid. However, currently it doesn't work with GNU screen as it doesn't support re-creating a hierarchy of sub-processes. They state that they want to achieve this in the future but the project doesn't seem to be too active at the moment. Nevertheless, you might want to trace their progress.

share|improve this answer
add comment

I built a similar thing on solaris years back. Not even screen-related; it was session related. "if $TTY = whatever". echox has the right idea.

tip: if you're doing this across multiple machines, recognize that each machine deserves its own definition of what should be done when you login there, rather than all being the same per your nfs mounted /home or similar.

HTH, -pbr

share|improve this answer
add comment

I've stumbled upon a project called screen-session. It allows you to save and reload GNU Screen sessions to some extent.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.