macOS Terminal scrollback not working on ssh to RPi

[Analog Kid]

I'm not sure this is the right forum for this question, but it seems the most likely to have people familiar with terminal.

I have a terminal profile that ssh's into a Raspberry Pi. I have the scrollback setting in the Terminal preferences set to "limit to available memory" (but have also had this problem with fixed limits of 10k lines).

For whatever reason, I can't scroll back more than a screenful or two.

Any ideas why? I'd assumed the scroll back depth is set by the client, not the server (ie. limited by my Mac not by the Pi), but maybe I have that wrong?

 

[chown33]

I've seen weird things happen in Terminal's scrollback after some app has used VT100 (or whatever) cursor controls. I've also seen it misbehave after the Terminal window session has been going for a long time, like say a few months straight (not unusual for me). FWIW, I'm using 10,000 lines of scrollback.

Cursor controls means an app that does something with cursor positioning, or clear screen (the VT100's ctl codes), or such things. Examples that come to mind were when I was using nano (or similar) running on the connected Pi to edit files residing on the Pi from my Mac's Terminal window. I don't know if that error was because the Terminal window's terminal emulator was imperfect, different from the Pi's termcap, or whatever. It wedged things twice and then I gave up and edited the files on the Mac using TextEdit, and wrote a simple shell script to run on the Mac that copies dir-trees across to the Pi (cp and rsync). That took less troubleshooting, since I was on a deadline, and I haven't bothered to go back and figure out where the scrollback problem is.


The problem with long-lived Terminal windows is something I see occasionally, and I have no idea what triggers it. The symptoms are pretty consistent: continuous scrollback is lost. Instead of being able to scroll back more than a window's worth of lines, the scrollback jumps backward some indeterminate number of lines, and intervening lines "don't exist". So if you had a bunch of lines like this:

e
x
a
m
p
l
e
-
i
l
l
u
s
t
r
a
t
i
o
n​

And the "ration" lines were showing in the Terminal window, scrolling back will skip backward to say "exam" and Terminal will neither show nor allow access to the "ple-illust" lines. You may have what seems to be contiguous lines selected, so you Copy to clipboard, then you'll see some lines are lost when you paste in another app.

When I see this problem and it becomes annoying, I close the Terminal window and reopen a new one. The history is still there if it's the same ptty (usually is), and the scrollback then works AFAICT.

 

[Analog Kid]

I've seen weird things happen in Terminal's scrollback after some app has used VT100 (or whatever) cursor controls. I've also seen it misbehave after the Terminal window session has been going for a long time, like say a few months straight (not unusual for me). FWIW, I'm using 10,000 lines of scrollback.

Cursor controls means an app that does something with cursor positioning, or clear screen (the VT100's ctl codes), or such things. Examples that come to mind were when I was using nano (or similar) running on the connected Pi to edit files residing on the Pi from my Mac's Terminal window. I don't know if that error was because the Terminal window's terminal emulator was imperfect, different from the Pi's termcap, or whatever. It wedged things twice and then I gave up and edited the files on the Mac using TextEdit, and wrote a simple shell script to run on the Mac that copies dir-trees across to the Pi (cp and rsync). That took less troubleshooting, since I was on a deadline, and I haven't bothered to go back and figure out where the scrollback problem is.


The problem with long-lived Terminal windows is something I see occasionally, and I have no idea what triggers it. The symptoms are pretty consistent: continuous scrollback is lost. Instead of being able to scroll back more than a window's worth of lines, the scrollback jumps backward some indeterminate number of lines, and intervening lines "don't exist". So if you had a bunch of lines like this:

e
x
a
m
p
l
e
-
i
l
l
u
s
t
r
a
t
i
o
n​

And the "ration" lines were showing in the Terminal window, scrolling back will skip backward to say "exam" and Terminal will neither show nor allow access to the "ple-illust" lines. You may have what seems to be contiguous lines selected, so you Copy to clipboard, then you'll see some lines are lost when you paste in another app.

When I see this problem and it becomes annoying, I close the Terminal window and reopen a new one. The history is still there if it's the same ptty (usually is), and the scrollback then works AFAICT.

Thanks for the confirmation. I can't figure out what's triggering the behavior. I notice it when I more <file> or cat <file>. It looks like compiler output is retained though in much greater depth... Just weirdness all around.

 

[chown33]

Thanks for the confirmation. I can't figure out what's triggering the behavior. I notice it when I more <file> or cat <file>. It looks like compiler output is retained though in much greater depth... Just weirdness all around.

I'm pretty sure more uses some cursor-control sequences. I know cat doesn't.

Try changing the terminal type (TERM env var) to something that has no termcap/curses entry. I vaguely recall there may be a terminal name like 'tty' that tells curses to not use any cursor-controls. The idea is to test the "cursor control sequences break things" hypothesis, by telling more, less, and friends to not emit any cursor-control sequences. If that solves the problem, then at least you've identified the domain.

EDIT
I tracked down the name of the plain terminal. I should have guessed one of the names would be 'dumb'.

$ toe | grep tty
dumb         80-column dumb tty
elks-glasstty    ELKS glass-TTY capabilities
glasstty     classic glass tty interpreting ASCII control characters
hp+labels     "standard" label info for new HP ttys
hp+printer    "standard" printer info for HP ttys
memhp         memory relative addressing for new HP ttys
putty         PuTTY terminal emulator
putty-256color    PuTTY 0.58 with xterm 256-colors
putty-vt100    VT100+ keyboard layout
qdss         qdss glass tty
scrhp         screen relative addressing for new HP ttys
tty33         model 33 or 35 teletype
tty37         model 37 teletype
tty40         teletype dataspeed 40/2
tty43         model 43 teletype
vanilla       dumb tty
vt100-putty    Reset PuTTY to pure vt100

Commands to list the dumb terminal's capabilities:

$ TERM=dumb
$ infocmp
#    Reconstructed via infocmp from file: /usr/share/terminfo/64/dumb
dumb|80-column dumb tty,
    am,
    cols#80,
    bel=^G, cr=^M, cud1=^J, ind=^J,

Another thing that comes to mind:
What terminal name is your Pi set to? Also, do the cursor-controls in that terminal's entry on the Pi match the ones resident on your Mac?

I'm wondering if the problem arises not simply because of cursor-control sequences, but because the Pi is emitting control sequences for the wrong terminal type, or with a different, damaged, or malformed terminal entry.