Hyperpolyglot

command line options | key bindings | customization | terminology | documentation

Command Line Options

Key Bindings

sessions | windows | regions | panes | paste buffer | copy mode

Customization

Terminology

server | client | session | window | region | pane

how ssh works:

When a user logs in to a remote host using ssh, the ssh process contacts an sshd process listening on TCP port 22. The sshd process opens up a new TCP port and forks off a copy of itself for communicating with the ssh process. The new port and child process are for the exclusive use of the connection being established.

The child sshd process authenticates the ssh process, and if it passes it creates a pseudo-terminal. It then forks the remote user's shell which becomes the controlling process for the pseudo-terminal.

If the network connection is closed, either explicitly by the ssh process or because of a loss of network connectivity, the child sshd process closes the pseudo-terminal, and this in turn causes the shell to exit.

the SIGHUP problem:

If the shell had any process groups running when it exits, they are sent a SIGHUP signal followed by a SIGCONT signal. By default processes exit when they receive SIGHUP. This makes it challenging to run long-running jobs on a remote host when the network connection is unreliable.

A simple solution to the SIGHUP problem is to run each job with nohup. If the user forgets to run a job with nohup, there is no way to protect the job from SIGHUP short of killing it and restarting it again.

Multiplexers offer a solution which protects the shell instead of the job. The user doesn't need to remember to run each job with nohup. As an added benefit any state kept by the shell is preserved.

server:

The multiplexer server creates pseudo-terminals which are used for running and interacting with programs.

Screen and Tmux servers can create multiple pseudo-terminals. The controlling process for each pseudo-terminal is the user's shell.

A Dtach server can only create one pseudo-terminal. The controlling process program is specified on the command line when the server is launched.

client:

To see the output of a shell the user must connect to the multiplexer server with a multiplexer client process.

If the multiplexer is being run on a remote machine and the user's connection is lost, the server and its terminals and controlling processes will persist, but the client process will exit.

When multiple client processes connect to the same server they can see the same output. This is a way to share a display across computers.

session:

Multiplexers support multiple sessions. Each multiplexer session has its own set of terminals and controlling processes which it is running. The client must choose a session to attach to, and will only be able to see the output of the controlling processes in that session. Sessions can be given names to make it easy for the client to choose the correct session.

Screen launches a separate server process for each session. Screen servers and clients communicate via named pipes.

Tmux by default will only run one server process per user, and this server process can have multiple sessions. A Tmux client and the server communicate via a Unix domain socket in the /tmp directory. The -L option can be used to specify a different socket; a new server is created for each socket.

Dtach runs a separate process for each session. Each session is identified by the Unix domain socket specified by the user when creating the session.

window:

Both Screen and Tmux have entities which they call windows.

A Screen window has a single pseudo-terminal and shell. A Tmux window can have multiple pseudo-terminals and shells.

Screen windows can share the viewport. The Tmux viewport can only display one window at a time.

Both Screen and Tmux windows are numbered starting from zero.

Dtach sessions can be regarded as having a single window with a single pseudo-terminal and controlling process.

region:

Screen can divide the viewport into multiple regions.

Screen regions can be empty or they can contain a window. The same window can be displayed in more than one region. When regions share a window their content is identical.

Screen regions are stacked on top of each other and extend the full width of the window.

pane:

Tmux can divide windows into multiple panes.

Tmux panes contain a single pseudo-terminal with a shell, and each pseudo-terminal and shell belongs to only one pane.

Tmux windows can be divided both horizontally and vertically into panes. Each division can be subdivided further.

Tmux panes are numbered.

Tmux panes can be moved between windows.

three examples of sessions:

command character (prefix):

Multiplexers pass most input on to the shell in the region with focus, but a special command character is used to send commands to the multiplexer.

The default command character in Screen is C-a. The keystrokes which follow C-a are interpreted by Screen instead of being passed to the shell.

Tmux calls the command character the prefix and the default value is C-b. The keystrokes following the prefix are interpreted by Tmux instead of being passed to shell.

Dtach has three command characters, which by default are C-\, C-l, and C-z. They are not used as prefixes; Dtach obeys only three commands.

scrollback buffer (history):

Screen and Tmux keep a history of the output of each shell. The maximum length of the output in lines is configurable.

Screen calls the history the scrollback buffer.

copy/scrollback mode (copy mode):

Screen and Tmux support two modes for each region. In default mode, input which is not intercepted by the multiplexer is passed to the shell.

When the region is in copy mode the region behaves like a read-only buffer of an editor. The contents are the output of the shell including output that may have scrolled off the top of the region.

The keybindings used by Screen in copy/scrollback mode are Vim-style. It is possible to customize them to be Emacs-style.

The Tmux calls copy/scrollback mode simply copy mode. The keybindings are by default Emacs-style.

paste buffer:

Screen has a single paste buffer.

Tmux has multiple paste buffers. The Tmux paste buffers are numbered; the most recent is number zero. Sessions share a common paste buffer history.

caption (status line):

When a Screen window is split into multiple regions, a caption line is placed at the bottom of each region. When a window contains a single region, Screen by default does not display a caption. The caption, when present, contains information from Screen. The information that is displayed can be customized.

Tmux calls the line at the bottom of a window the status line. By default it is always displayed, though it can be turned off. The status line contains information from Tmux which can be customized.

Documentation

man nohup
Screen User's Manual
man tmux
man dtach