On Thu, Jan 30, 2020 at 08:11:30PM -0500, Thomas Dickey wrote:
...
The logfile doesn't give a clue about the screensize; there's no
cursor movement in it other than to the home-position.
Using unmap, which prints the escapes in visible form (and happens
to split the lines on escape characters), I see something a little
odd. Here's a little slice from that listing:
\E]2;vinc17@zira - ~ | pts/23^G
\E(B
\E(B
\E[m
\E[?12l
\E[?25h
\E[?1007l\r
\E[0m
\E[27m
\E[24m
\E[J
\E[40m
\E[93mzira:~,2>
The odd part is the (xterm-specific)
\E[?1007l\r
(the "\r" isn't part of the sequence, but that's how unmap presents it).
XTerm Control Sequences summarizes this:
Ps = 1 0 0 7 -> Disable Alternate Scroll Mode, xterm. This
corresponds to the alternateScroll resource.
The manual page gives a little more information:
alternateScroll (class ScrollCond)
If “true”, the scroll-back and scroll-forw actions send
cursor-up and -down keys when xterm is displaying the
alternate screen. The default is “false”.
The alternateScroll state can also be set using a control
sequence.
The changelog tells a little more:
Patch #291 - 2013/02/26
* add validity check for xterm widget parameter to AlternateScroll
function, needed to handle wheel mouse events in the scrollbar
area since [451]patch #282 changes which introduced
alternateScroll feature (Redhat #874327).
Earlier in the output of unmap, it's switching to the alternate screen:
\E[?1049h
but then switches back out before the 1007's. Just to check, I ran xterm
with that disabled, and it made no difference.
However, looking at the trace for something that might set the top/bottom
margins, I see a case (this time from Trace-parent.out):
parse 001B -> CASE_ESC ansi_table (used=0)
params 0 (0)
parse 006C -> CASE_HP_MEM_LOCK esc_table (used=0)
CASE_HP_MEM_LOCK
set_tb_margins 16..23, prior 0..23
That's documented in XTerm Control Sequences:
ESC l Memory Lock (per HP terminals). Locks memory above the cursor.
and it comes from (unmap) this section of the logfile:
\E[00;92mcryptsetup
\E[0m/
\Els: cannot open directory '/run/cups/certs': Permission denied\r
\nls: cannot open directory '/run/firejail/firejail.ro.dir': Permission denied\r
\n[m\r
xterm's doing what it's documented to do.
So... (see my previous message), there's no way for xterm (or any terminal)
to distinguish your shell's stdout from stderr. There's only the usual
solution, which assumes that applications which spit out both will do
fflush's to keep the two in sync.
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
Attachment:
signature.asc
Description: PGP signature