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

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

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

From: Anthony Howe <achowe%snert.com@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: Tue, 16 Apr 2024 07:57:27 -0400

 On 2024-04-15 22:40, David Holland wrote:
 > 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: Tue, 16 Apr 2024 02:36:31 +0000
 > 
 >   On Tue, Apr 16, 2024 at 02:10:02AM +0000, David Holland wrote:
 >    >  One could argue that getnstr/mvgetnstr in cbreak mode should handle
 >    >  simple line editing, but it does not, and there are problems with
 >    >  doing so. (For example: how simple? Tty cooked mode editing is fairly
 >    >  straightforward, but also not particularly useful or adequate since
 >    >  it's no longer 1983, but anything more complicated gets into religious
 >    >  questions like whether you should move to the beginning of the line
 >    >  with ^A or esc-^-i or what.)
 >   
 >   Hmm. I take it back, apparently it does. This behavior is
 >   undocumented, and that's a bug. It's also lacking support for werase.
 >   And EOF, and REPRINT. And what about STATUS? Or INTR/QUIT/SUSP?
 
 Historically Curses does not handle werase.  There is no equivalent of 
 erasechar() or killchar() for werase.
 
 INTR/QUIT/SUSP are signals (not line editing) which are handled by cbreak() and 
 raw() family.
 
 Curses has never supported `readline` for vi/emacs line editing.  That would be 
 an extension to historical behaviour.
 
 >   The whole thing seems like a can of worms and a mistake, if you ask
 >   me.
 
 Nope.  Historical.
 
 >   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.  And kill typically defaults to stty ^U.  The 
 problem when stdin is not a tty, is that termios does not apply so all the 
 special keys are zero.
 
 In theory, Curses could `open(ctermid(NULL), ...)` a separate tty to get the 
 user's stty settings then apply them to the redirected stdin.
 
 -- 
 Anthony C Howe
 achowe%snert.com@localhost                                   BarricadeMX & Milters
 http://nanozen.snert.com/                          http://software.snert.com/