The contents of the session were already overwritten, when you started up the TUI programs in the first place. You can see that that is the case.
When a TUI program, that uses ncurses
and suchlike to present its textual user interface, starts up, it clears the screen. At that point, everything that is on the screen has been overwritten.
What you're missing, and what you don't know the name for, is the idea of terminals that have an alternate screen buffer. When such a TUI program as these starts up, it issues the escape sequence to switch to the terminal's alternate screen buffer, if it has one. All of its output then goes onto that buffer. When the program exits, or suspends itself, it issues the escape sequence to restore the primary screen buffer, which has remained untouched whilst the TUI program has displayed its user interface on the alternate buffer.
For terminals that don't have alternate screen buffers, there's no escape sequence to issue, and the full-screen user interface overwrites what was previously on the terminal.
Programs look these escape sequences up in the terminfo
or termcap
databases. In the terminfo
world the terminal capabilities are named smcup
and rmcup
. In the termcap
world they are named ti
and te
. As documented they make no mention of screen buffers.
Instead they talk of entering and exiting "cursor addressing mode". The notion is that a TUI program that presents a full-screen interface like this is operating in cursor addressing mode where the program really doesn't need the terminal to scroll; whereas a TUI program that just outputs scrolling lines of text is not. So one switches into and out of this mode. (In the real world, things are not so clear cut. For example: Modern shells such as the Z Shell move the cursor about for line editing, menu completion, and $RPROMPT
; but don't switch to the alternate screen buffer, don't have a fully-fledged full screen user interface, and operate in terms of scrolling.)
The capabilities thus usually do more than just switch buffers. smcup
also contains the escape sequence for saving the current cursor position, and rmcup
the escape sequence for restoring it, as well, if the terminal has such escape sequences.
Your problem is one of two things:
- The
termcap
database on your FreeBSD system doesn't have te
and ti
entries for your particular terminal type, because the entry is incomplete.
- You aren't using the right terminal type for your terminal emulator in the first place.
The terminal type is taken from your TERM
environment variable, on the server end. Its value denotes an entry in the termcap
database. So ensure that your TERM
environment variable names an entry in /etc/termcap
with the capabilities that match those of your (local) terminal emulator. If there's no entry matching your terminal emulator that contains ti
and te
, then you'll have to simply add such an entry.
It sounds like his emulator supports
ti
andte
, and hisTERM
environment variable names an/etc/termcap
entry which setsti
andte
to the appropriate escape codes. Various apps are outputting those codes and he doesn't like the resulting screen buffer switching. So the advice should be to choose an entry which omitsti
andte
. If a custom entry (or override of an existing one) is needed, instead of editing/etc/termcap
, he could put it in~/.termcap
or theTERMCAP
environment variable. – Mike Brown – 2015-03-18T11:36:18.113Assuming he's using tcsh, this should disable
ti
andte
no matter what his terminal type is:setenv TERMCAP ${TERM}:ti@:te@:tc=${TERM}
– Mike Brown – 2015-03-18T12:03:57.760You haven't looked at the picture in the question, and have things backwards. – JdeBP – 2015-03-18T17:22:27.243
Indeed, the screenshot is crucial, and you are correct. I was confused because I'm accustomed to operating in a terminal without
ti
/te
, so when I switch to a terminal that does have that feature, I say the exact same kind of thing he did: "my session gets overwritten," meaning my nano/less/vi/whatever session has disappeared and has been replaced by whatever I was doing before. I see from the screenshot though that he was talking about the opposite situation. – Mike Brown – 2015-03-19T09:38:30.397