Re: lib/58151: Should Curses getnstr() family handle erase and kill characters when input is not a tty?

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/58151: Should Curses getnstr() family handle erase and kill
 characters when input is not a tty?
Date: Wed, 17 Apr 2024 16:20:36 +0000

 On Tue, Apr 16, 2024 at 12:00:05PM +0000, Anthony Howe wrote:
  >  Historically Curses does not handle werase.  There is no equivalent of 
  >  erasechar() or killchar() for werase.
 
 Historically certain old and broken systems don't have werase in the
 tty driver either. But if we're going to argue that in this particular
 combination of circumstances curses should pretend to be tty cooked
 mode, it should be the same cooked mode as the tty driver, not the
 cooked mode from SVr2.
 
 In principle it ought to also support silly archaic modes like ECHOKE
 too, although since the tty driver doesn't support that one either
 it's not exactly critical.
 
 However, nothing in that code handles echo vs. noecho modes correctly.
 
  > INTR/QUIT/SUSP are signals (not line editing) which are handled by
  > cbreak() and raw() family.
 
 Yes, so if we're in cbreak mode and curses is pretending to be a tty
 because its input is a pipe, it ought to post SIGINT if it receives a
 ^C down that pipe.
 
  > Curses has never supported `readline` for vi/emacs line editing.
  > That would be an extension to historical behaviour.
 
 Yes, so? Today all serious programs that handle line input use
 readline or libedit (or implement it by hand) and that's the minimum
 expectation. Curses could behave like libedit here, and that would be
 more consistent with user expectations.
 
 (Except that curses apps that intend to meet user expectations don't
 use this pathway because it doesn't, either currently, historically,
 or portably, meet those expectations.)
 
  >> The whole thing seems like a can of worms and a mistake, if you ask
  >> me.
  >  
  >  Nope.  Historical.
 
 ECHOKE is historical too.
 
  >>   Anyway, it appears that if curses thinks it's not on a tty, both
  >>   erasechar() and killchar() return 0. What happens if you send 0 down
  >>   the pipe? If that causes an erase, and it looks like it will, that
  >>   seems like undesirable behavior and erasechar() ought to default to ^H
  >>   or ^? when not on a tty. (But, which?)
  >  
  > By definition BS = backspace = ^H.
 
 Historically erase is ^?, not ^H.
 
  > In theory, Curses could `open(ctermid(NULL), ...)` a separate tty
  > to get the user's stty settings then apply them to the redirected
  > stdin.
 
 That's just going to cause more problems.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost