XFCE4 terminal doesn't reset back to the top and I can scroll up to the output

[dbeckwith]

It seems like after a recent update the clear screen option doesn't properly clear the screen anymore. My terminal doesn't reset back to the top and I can scroll up to the output of previous runs. It's possible I'm mistaken but I thought the usual behavior was that you couldn't scroll back to output of previous runs, so if I scroll up all the way I just get to the top of the current run.

I also now see this message every time I Ctrl+C cargo watch:

watchexec::run: 2021-08-24T19:49:13.045-04:00 - WARN - Could not pass on signal to command: I/O error: No such process (os error 3)

I tried running with --debug but didn't see anything suspicious or seemingly related to clearing the screen/TTY stuff.

I'm using:

• cargo-watch 7.8.1
• cargo 1.55.0-nightly (27277d966 2021-07-16)
• xfce4-terminal 0.8.7.4
• Xubuntu 18.04.5/Linux 4.15.0-154-generic

[dbeckwith]

Just found watchexec/cargo-watch#160, seems very similar. Running tput reset in my terminal does what I'm expecting cargo watch -c to do.

[passcod]

What shell are you using and what's the value of TERM?

[passcod]

That warning is known (will go away in a future update): it tries to pass on the SIGINT but the command has already exited; better tracking of the command state is coming, fixing this.

[passcod]

Also: are you using tmux or some other mux (screen etc)

[dbeckwith]

• fish, version 3.3.1
• TERM=xterm-256color
• No other mux

[passcod]

And vte version if you can get that. Also what does tput clear do? And while we're at it, the outputs of tput reset | hexdump -C and for tput clear | hexdump -C

That said, watchexec only runs the clear, not the reset. tput clear does work here (I'm running xfce term 0.8.10/vte 0.64.2 as daily driver).

[dbeckwith]

How do I get the vte version?

tput clear seems to print enough newlines to scroll my prompt up to the top of the window, so when I scroll back I see lots of blank lines and then my previous prompt.

tput reset erases my entire scrollback history, which is what I thought cargo watch -c did previously.

~> tput reset | hexdump -C
00000000  1b 63 1b 5d 31 30 34 07  1b 5b 21 70 1b 5b 3f 33  |.c.]104..[!p.[?3|
00000010  3b 34 6c 1b 5b 34 6c 1b  3e                       |;4l.[4l.>|
00000019
~> tput clear | hexdump -C
00000000  1b 5b 33 4a 1b 5b 48 1b  5b 32 4a                 |.[3J.[H.[2J|
0000000b

[passcod]

(Reset does a lot more, as you can see, which can be unwanted.)

Wow, okay, something is very weird here, that clear sequence is wrong.

3J clears the scrollback. H resets the cursor position and 2J clears the screen. In xfce that's done by inserting blank space to push the current output off the screen. The usual sequence is 3J after the H 2J, such that it clears that blank space as part of the scrollback.

Could you give you ncurses version (should be in tput -V) and also compare the behaviour of just the clear command? (Both behaviour and via hexdump)

[dbeckwith]

Interesting...

~> tput -V
ncurses 6.1.20180127

clear looks like it does the same as tput clear

~> clear | hexdump -C
00000000  1b 5b 33 4a 1b 5b 48 1b  5b 32 4a                 |.[3J.[H.[2J|
0000000b

[passcod]

Right, one more: if you wouldn't mind installing

cargo install --example clscli clearscreen

and running it with

clscli auto
clscli auto | hexdump -C

I'm expecting Terminfo... which would still make the behaviour make zero sense but let's get certainty as to what's running here (making a note too to add this info to a debug log in cargo watch).

[passcod]

Also yeah, clear is literally an alias for tput clear, unless it's overridden by the shell (some shells do this)

[passcod]

Alright, read through some C source (paiiiiin)... So: clearscreen should be doing this properly (it should be selecting Terminfo and that implements the correct logic), but this correct logic was only introduced in tput in ncurses 6.1 20180804.

I'm not sure how it's possible that something else than Terminfo (which imitates the correct post-august-2018 tput) or XtermClear (which is a hardcoded H 2J 3J sequence) or VtRis (which would do something else entirely but at least would clear) is selected. As per the code and the likely versions, it isn't. Happy to be proven wrong if the clscli tool above says so.

If it's selecting TputClear, then it's literally calling tput clear, and therefore would be the issue (due to your tput being the old incorrect version).

If it's selecting Terminfo and generating the wrong 3J H 2J sequence, your terminfo database may be at issue, though the only way for it to produce this would be to have the "clear screen" sequence defined as 3J H 2J, and the E3 sequence to not exist. Which is all kinds of messed up.

If that's the case, I could feasibly detect and fix that.

[dbeckwith]

clscli auto appears to have the same effect as tput reset, it clears my scrollback.

~> clscli auto | hexdump -C
00000000  76 61 72 69 61 6e 74 20  3d 20 54 65 72 6d 69 6e  |variant = Termin|
00000010  66 6f 2c 20 73 6c 65 65  70 69 6e 67 20 31 20 73  |fo, sleeping 1 s|
00000020  65 63 6f 6e 64 0a 1b 5b  48 1b 5b 32 4a 1b 5b 33  |econd..[H.[2J.[3|
00000030  4a                                                |J|
00000031

[passcod]

Right, if you force-install cargo-watch again, so long as you don't use --locked, it will pick up 1.0.7 which I believe will fix it.

[dbeckwith]

Yep that did it, working great now, thanks!