Re: lib/57867: Why does cbreak or raw affect terminal output differently?

[Anthony Howe <achowe%snert.com@localhost>]

The following reply was made to PR lib/57867; it has been noted by GNATS.

From: Anthony Howe <achowe%snert.com@localhost>
To: gnats-bugs%netbsd.org@localhost, lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
 differently?
Date: Thu, 25 Jan 2024 18:07:12 -0500

 On 2024-01-25 17:00, Brett Lymn wrote:
 >   >  The SUS Curses Issue 7 talks about cbreak(), raw(), nl() as functions affecting
 >   >  input only (no mention about output).  Yet tty.c, raw(), disables `OPOST` that
 >   >  influences output and cbreak() leaves what ever the termios oflag has set by stty.
 >   >
 >   
 >   I am not entirely sure and susv2 is not really clear on what the effect the calls have on
 >   output processing.  My guess is OPOST is cleared in raw() to prevent special character
 >   processing affecting the screen contents.  I expect that this behaviour has been there for a
 >   very long time so we would need to look very carefully at changing it.  Having said that,
 >   the bug that RVP pointed to dated back to the original import.
 >   
 >   If you are adventurous you can modify tty.c to remove the output flags for raw mode and test
 >   it.
 
 I went down that road long ago at MKS with their Curses library; it was messy. 
 I'd have better luck getting SUS Curses to correctly document historical 
 behaviour than play with OPOST and all the issues that raises and possibly 
 breaking existing programs.
 
 Oddly enough I took some time yesterday to play with my regression test and 
 created a textual TERM definition.
 
 textterm|Minimalist Textual Test,
 	am, xon,
 	cols#80, lines#24,
 	bel=<BEL>\r\n,
 	cr=<CR>,
 	nel=<NL>\r\n,
 	ind=<IND>\r\n,
 	clear=<CLEAR>\r\n,
 	ed=<ED>\r\n,
 	el=<EL>\r\n,
 	cub1=<CUB1>\r\n,
 	cud1=<CUD1>\r\n,
 	cup=<%i%p1%d;%p2%d>\r\n,
 	home=<HOME>\r\n,
 	rmso=<RMSO>\r\n,
 	smso=<SMSO>,
 
 Then twiddle the program code between cbreak() and raw().  The tests pass in in 
 both versions.  In email with Valery Ushakov, I speculated that:
 
 > I think there are some under the hood algorithm choices about when a CR is a
 > CR and LF is a LF and when they can be used with or without OPOST set.  When
 > you redefine `cr`, `nel`, `cud1`, and `ind` to be longer strings it appears
 > to force a consistent output choice.
 Essentially I think that when certain capabilities are defined as \r, \n, and 
 \b, the output varies because of OPOST on/off.  Set them to something different 
 (longer), then a particular code path is consistently used for cbreak() and raw().
 
 Anyway.  By the sounds of it there is no bug per-se, just confusion and 
 ambiguity with respect to SUS and historical behaviour.
 
 Might was well close this as `WON'T FIX`.  I have a work around with the above 
 `TERM=textterm`, I'll live with that.
 
 Thank you for your time and attention,
 
 -- 
 Anthony C Howe
 achowe%snert.com@localhost                                   BarricadeMX & Milters
 http://nanozen.snert.com/                          http://software.snert.com/