Difference between revisions of "Screen notes"

From Noah.org
Jump to navigationJump to search
Line 29: Line 29:
 
Download [http://www.noah.org/downloadsvn.php?src=file:///home/svn/src/dotfiles/.screenrc .screenrc]
 
Download [http://www.noah.org/downloadsvn.php?src=file:///home/svn/src/dotfiles/.screenrc .screenrc]
 
<include svncat src="file:///home/svn/src/dotfiles/.screenrc" highlight="sh" />
 
<include svncat src="file:///home/svn/src/dotfiles/.screenrc" highlight="sh" />
 +
 +
== Start a screen session with multiple screens ==
 +
 +
I don't know why `screen` doesn't allow you to start multiple screens from a single command-line invocation. Say you want to start a screen session with 5 screens already started connected to 5 hosts. This is a common use-case for me. But it is not too hard to trick `screen` into doing this. It's a little ugly, but it's fairly easy and simple.
 +
 +
The `screen` command has an option, "-c file", which overrides the default configuration file in ~/.screenrc. You can put screen commands in this file that will get executed when the session starts. Unfortunately this overrides your config options in ~/.screenrc, but you can copy the commands from your ~/.screenrc to the head of your custom screenrc. For example, the following commands could be saved in a file called "five_hosts_screenrc":
 +
 +
<pre>
 +
startup_message off
 +
defscrollback 10000
 +
hardstatus alwayslastline
 +
hardstatus string "%{kG}%50>%-w%{ky}%n %t%{-}%+w%{-} %>%=%{ky}Ctrl-A ?%{-} for help"
 +
screen -t Host100 ssh 192.168.1.100
 +
screen -t Host101 ssh 192.168.1.101
 +
screen -t Host102 ssh 192.168.1.102
 +
screen -t Host103 ssh 192.168.1.103
 +
screen -t Host104 ssh 192.168.1.104
 +
</pre>
 +
 +
You would then invoke this configuration with the following command:
 +
 +
<pre>
 +
screen -c five_hosts_screenrc
 +
</pre>
 +
 +
That will start a session with all five hosts attached to one of the screens.
  
 
== multiuser sessions ==
 
== multiuser sessions ==
  
The `screen` command must be setuid root. This is a security vulnerability, so learn what setuid root means before you do this. As a rule of thumb, setuid is fine for a desktop developer's box, but a bad idea for a production machine. You may also need to set permissions for /var/run/screen to 755.
+
The `screen` command must be setuid root. This is a security weakness, so learn what setuid root means before you do this. As a rule of thumb, setuid is fine for a desktop developer's box, but a bad idea for a production machine. You may also need to set permissions for /var/run/screen to 755.
  
 
<pre>
 
<pre>
Line 45: Line 71:
  
 
The session owner starts screen. The owner should give it a name so it is easy to find.
 
The session owner starts screen. The owner should give it a name so it is easy to find.
 +
 
<pre>
 
<pre>
 
screen -S shared
 
screen -S shared
 
</pre>
 
</pre>
 +
 
Once screen has started the session owner needs to turn on multiuser mode and allow a given friend access.
 
Once screen has started the session owner needs to turn on multiuser mode and allow a given friend access.
 +
 
<pre>
 
<pre>
 
C-a :multiuser on
 
C-a :multiuser on
Line 55: Line 84:
  
 
The friend will then start screen and tell it to connect to the owner's session.
 
The friend will then start screen and tell it to connect to the owner's session.
 +
 
<pre>
 
<pre>
 
screen -x owner/shared
 
screen -x owner/shared

Revision as of 18:41, 18 July 2008

Minimal GNU Screen

`Screen` allows you to start shells and disconnect and reconnect them from any location. You can start a shell at work; disconnect; go home and reconnect to the same shell. A single screen session can group multiple shells. A user can have multiple screen sessions.

command-line screen arguments

  • `screen` -- start new screen session with one virtual screen.
    • C-a d -- disconnect the session. The session continues in the background as a daemon. You can reconnect later.
  • `screen -r` -- reconnect to a disconnected session.
  • `screen -rd` -- force a disconnect of a connected session and then reconnect.

control commands inside of screen session

  • C-a ? -- Show help
  • C-a d -- Disconnect
  • C-a c -- Create New virtual screen in the current session
  • C-a n -- Next screen
  • C-a p -- Previous screen
  • C-a esc -- Enter Copy/Scrollback mode (esc again to exit scrollback mode). Scrollback mode is very useful.
    • Use Vi-like keys to move around the scrollback history (the usual h,j,k,l for cursor, C-u for half page UP, C-d for half page DOWN).
    • Press SPACE to start selecting a region. Press SPACE again to Yank the region.
    • Press "C-a ]" to paste the yanked text into the current screen.

.screenrc

This is the .screenrc I use. It isn't complicated, but it does show you clearly which screen you are attached to and I like the status bar that shows how to get help. This is a helpful failsafe for users that forget "C-a ?" :-)

Download .screenrc <include svncat src="file:///home/svn/src/dotfiles/.screenrc" highlight="sh" />

Start a screen session with multiple screens

I don't know why `screen` doesn't allow you to start multiple screens from a single command-line invocation. Say you want to start a screen session with 5 screens already started connected to 5 hosts. This is a common use-case for me. But it is not too hard to trick `screen` into doing this. It's a little ugly, but it's fairly easy and simple.

The `screen` command has an option, "-c file", which overrides the default configuration file in ~/.screenrc. You can put screen commands in this file that will get executed when the session starts. Unfortunately this overrides your config options in ~/.screenrc, but you can copy the commands from your ~/.screenrc to the head of your custom screenrc. For example, the following commands could be saved in a file called "five_hosts_screenrc":

startup_message off
defscrollback 10000
hardstatus alwayslastline
hardstatus string "%{kG}%50>%-w%{ky}%n %t%{-}%+w%{-} %>%=%{ky}Ctrl-A ?%{-} for help"
screen -t Host100 ssh 192.168.1.100
screen -t Host101 ssh 192.168.1.101
screen -t Host102 ssh 192.168.1.102
screen -t Host103 ssh 192.168.1.103
screen -t Host104 ssh 192.168.1.104

You would then invoke this configuration with the following command:

screen -c five_hosts_screenrc

That will start a session with all five hosts attached to one of the screens.

multiuser sessions

The `screen` command must be setuid root. This is a security weakness, so learn what setuid root means before you do this. As a rule of thumb, setuid is fine for a desktop developer's box, but a bad idea for a production machine. You may also need to set permissions for /var/run/screen to 755.

sudo chmod u+s `which screen`
sudo chmod 755 /var/run/screen
  • `screen -S session_name` -- Start a new session with a given name. This makes it easier to find with `screen -ls` described below.
  • `screen -ls` -- list the available sessions.
    • `screen -ls username/` -- list the sessions of a given user. Note the trailing slash.
  • `screen -x username/sessionname` -- connect to a connected session. Use this to share sessions with other people. This is much like `kibitz`.

The session owner starts screen. The owner should give it a name so it is easy to find.

screen -S shared

Once screen has started the session owner needs to turn on multiuser mode and allow a given friend access.

C-a :multiuser on
C-a :acladd friend_username

The friend will then start screen and tell it to connect to the owner's session.

screen -x owner/shared

scripting screen

You can start a new screen sessions and then send screen commands to that session to have it open new virtual screens. This example starts a screen session and then creates ssh connections to five machines. Finally, you can reconnect to the session and use these screens. This will only work if you have public key certs setup for these machines.

screen -S foo_name -d -m
screen -S foo_name -X screen ssh 192.168.1.100
screen -S foo_name -X screen ssh 192.168.1.101
screen -S foo_name -X screen ssh 192.168.1.102
screen -S foo_name -X screen ssh 192.168.1.103
screen -S foo_name -X screen ssh 192.168.1.105
# select and kill does not always work.
#screen -S foo_name -X select 0
#screen -S foo_name -X kill
screen -S foo_name -r

The "select 0" and "kill" are needed to get rid of the initial virtual screen that was created when the screen session was started with '-d -m'.