Some programs like vim/nano/nload has the ability to use the whole terminal to display its content and upon exiting, the previous terminal output is restored. How do they implement this restoring process?

  • 2
    printf \\33\[\?1047h prints the xterm private mode escape sequence for switching to the alternate screen buffer (which does not store a scrollback) and printf \\33\[\?1047l swaps back. – mikeserv Nov 16 '15 at 2:30
  • @mikeserv How about that trap stty -g technique? – RobertL Nov 16 '15 at 2:38
  • @RobertL - stty affects the termios structure of the kernel-managed serial device. any changes made that way aren't directly related to what the user-space terminal program does. doing stty -echo;printf \\33\[\?1047h will still result in no output when you press keys - the terminal program (like xterm) is reading input from the [pt]ty device and writing it to the screen. it intercepts some escapes and performs certain functions, but not at the same level stty changes do. – mikeserv Nov 16 '15 at 2:44
  • @RobertL - none of that is meant to imply that trap and terminal escapes cannot be usefully combined, of course. they are very handy when paired, actually. – mikeserv Nov 16 '15 at 2:47
  • @mikeserv This may be an over-simplification on a different level, but I always thought that programs like vi (console) or the curses library would save the stty settings, then set raw mode and do all io direct to the tty, filtered through termcap style library (TERM variable), controlling the screen directly, and then restore the stty settings at exit. In that sense, I think the character codes to switch buffers are interpreted by xterm's emulation of the console. In that way I thought the stty settings might apply as the questioner mentioned "use the whole terminal to display".kkk – RobertL Nov 16 '15 at 5:27

How do they implement this restoring process?

They don't. It's not theirs to implement.

This is the so-called alternate screen buffer being switched in and out. It's implemented in the terminal (or terminal emulator program) itself. The terminal responds to control sequences that are emitted by such TUI programs. The TUI programs control when this happens, but the implementation of what happens is entirely within the terminal. Indeed, the TUI programs don't even have the same model of what is happening. To them, they are switching into and out of "cursor addressing mode".

Not all terminals and terminal emulator programs even have an alternate screen buffer. For example: the terminal emulator programs built into Linux and BSD kernels that provide their kernel virtual terminals usually don't have this capability.

On such terminals, there is no control sequence. The termcap/terminfo database record for the terminal type will, consequently, not have such control sequence; and switching to and from "cursor addressing mode" overwrites the current screen content without saving and restoring it.

vim, nano, and whatnot have no knowledge of this. They aren't doing anything different. They aren't what performs the function. They are simply emitting the control sequences that termcap/terminfo tell them will enter and exit "cursor addressing mode". For some terminals, that have the mechanism, "cursor addressing mode" also means use the alternate screen buffer. For some, that have not, it does not.

Further reading

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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