Re: suppressed ACS characters, ignpar, brkint, and imaxbel

[Thomas Dickey]

On Thu, Oct 03, 2024 at 05:24:14AM -0500, G. Branden Robinson wrote:
> At 2024-09-28T22:59:44-0500, G. Branden Robinson wrote:
> > From time to time over the years I've noticed that sometimes terminal
> > emulators (usually xterm in my case) get screwed into some state where
> > ACS characters just don't work.  I get the ugly 'qqqqqqqqx' nonsense
> > where box borders should be.
> > 
> > I've tracked it down this far:
> > 
> > $ diff -u /tmp/{good,bad}
> > --- /tmp/good   2024-09-28 22:49:05.858771398 -0500
> > +++ /tmp/bad    2024-09-28 22:49:13.826766470 -0500
> > @@ -3,8 +3,8 @@
> >  eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = 
> > ^R;
> >  werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
> >  -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
> > --ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon 
> > -ixoff
> > --iuclc -ixany imaxbel iutf8
> > +-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon 
> > -ixoff
> > +-iuclc -ixany -imaxbel iutf8
> >  opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 
> > vt0 ff0
> >  isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
> >  echoctl echoke -flusho -extproc
> 
> This may have been a red herring, or at least an incomplete indication
> of the trouble.  I've isolated the following further details:
> 
> 1.  The state xterm gets screwed into can be caused by catting a binary
>     file to the terminal.  What I think happens is that some of this
>     binary content masquerades as a terminal-control escape sequence.
> 
> 2.  The same binary file, once it's done being output, leaves garbage at
>     the shell prompt which will be read as input.  I thought these
>     problems had been found and fixed years ago?
> 
> These seem to be separate problems; some PDFs seem to cause problem #2
> but not #1.
> 
> I'm attaching a PDF that does only #2 (grodvi.1.2024-09-27.pdf) and one
> that does both #1 and #2 (meintro.2024-09-27.pdf).

hmm - there are a lot of escape characters.  PDFs are hard to "fix", because
they don't follow the rules that terminals use for escape sequences.  A
compressed binary file isn't intended to be viewed in that manner.

Using my "unmap", I see a little over 200 occurrences in each file
(and also of course a lot of characters that are C1 controls).

Briefly - ACS is only a small part of that.  "tput rmacs" is going to
switch back from alternate character set, and (I overlooked) terminal
descriptions with enacs will fix that too.

Things that are getting input are probably control sequences which
ask for a response from the terminal, such as those which identify
the type of terminal, those which tell where the cursor is.  Most of
those are "only" numbers and some punctuation, which can be a nuisance.
fwiw, Debian configures xterm to disable the responses which can be
more than numbers/punctuation, but since they don't communicate with
upstream on any of that, it's possible to have disagreements.

I seem to recall an application which one could feed data to and
have it only show what it would interpret, but don't recall the name.
It wouldn't be complete, anyway.

"reset" will clear the screen as a side-effect :-)
 
> I'd like to know if (a) anything more can be done to prevent problem #2,
> and (b) what terminal capability seems to be disabling group switching
> in UTF-8 mode.  (There's an "enacs" [for "enable ACS"] but no
> counterpart to disable it?)
> 
> Regards,
> Branden






-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature