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

[RVP <rvp%SDF.ORG@localhost>]

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

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: uwe%netbsd.org@localhost, blymn%netbsd.org@localhost, dickey%invisible-island.net@localhost
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
 differently?
Date: Fri, 26 Jan 2024 00:43:15 +0000 (UTC)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
 
 --0-1428639238-1706229795=:27462
 Content-Type: text/plain; format=flowed; charset=UTF-8
 Content-Transfer-Encoding: 8BIT
 
 On Wed, 24 Jan 2024, Valery Ushakov wrote:
 
 > It was not clear from the original question if input was involved,
 > presumably yes, so there may be differences.
 >
 > I can't quite remember all the nuances, so when I need to, I check
 > this table from SCO UNIX Development System, User Interface Guide:
 >
 > [...]
 >
 
 Thanks for that table, but, that too, is only concerned with input behaviour.
 I emailed Tom Dickey to find out how ncurses handled this, and I reproduce
 his answers below:
 
 ---START E-MAIL 1---
 > Does ncurses produce different _output_ depending on whether cbreak() or raw()
 > has been called?
 
 no - it only affects input processing - but that includes whether control
 characters are echoed or not.  I don't believe that's what you are asking
 about, though.
 
 > This question was asked in NetBSD PR #57867:
 > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57867
 
 > The answer, for BSD curses, seems to be yes, but, I can't see precisely what
 > or why.
 
 ncurses doesn't change OPOST, while NetBSD turns it off in raw but not
 cbreak (as well as turning on ONLCR - but ncurses turns that off in initscr).
 
 NetBSD's nl/nonl use a detail which ncurses doesn't do anymore:
 
 20201003
  	+ remove output-related checks for nl/nonl (report by Leon Winter).
 
 The bug report has a different story from what I found while researching
 this.  Here's what I decided to document:
 
         From the outset, ncurses used nl/nonl to control the conversion of newâ??
         lines  to  carriage  return/line-feed  on output as well as input.  XSI
         Curses documents only the use of these functions for input.  This  difâ??
         ference  arose  from  converting  the  pcurses source (which used ioctl
         calls with the sgttyb structure) to termios (i.e., the  POSIX  terminal
         interface).  In the former, both input and output were controlled via a
         single option CRMOD, while the latter separates  these  features.   Beâ??
         cause that conversion interferes with output optimization, nl/nonl were
         amended after ncurses 6.2 to eliminate their effect on output.
 ---END E-MAIL 1---
 
 ---START E-MAIL 2---
 > Cool! I suppose this is going to go into the new ncurses.3x coming this
 > weekend?
 
 It's been there a couple of years (I quoted the NEWS item from 2020).
 
 Whenever Branden gets tired of bombarding me with formatting changes,
 I've a few things to finish off for ncurses 6.5
 
 > Can I quote your answer when I reply to the PR? I'll CC: you, of course.
 
 sure - my point in the manpage was that the original BSD curses tied the
 input/output together because of the underlying calls, but that X/Open
 Curses didn't need or actually want that.
 
 Actually, Solaris kept the feature: in its xcurses, it sets OPOST and ONLCR
 with nl(), and clears them with nonl().  But the more commonly used SVR4
 curses just clears both in newscreen.c:
 
          /* set tty settings to something reasonable for us */
 #ifdef  SYSV
          PROGTTYS.c_lflag &= ~ECHO;
          PROGTTYS.c_lflag |= ISIG;
          PROGTTYS.c_oflag &= ~(OCRNL|ONLCR); /* why would anyone set OCRNL? */
 #else   /* SYSV */
          PROGTTY.sg_flags &= ~(RAW|ECHO|CRMOD);
 #endif  /* SYSV */
 
 iirc, Solaris xcurses comments indicate that it was developed by MKS,
 and has several differences from SVr4 curses.  The source code is viewable
 on illumos-gate, though of course there's no history before 2005, and only
 comments here and there to help.
 
 So... after investigating this a few years ago, I agreed with Leon
 that it shouldn't affect output processing, and documented it.
 ---END E-MAIL 2---
 
 -RVP
 --0-1428639238-1706229795=:27462--