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

[Brett Lymn <blymn%internode.on.net@localhost>]

Before I sort through the below, I will addres the original statement
about the output and what is expected to happen.

It looks like there is some expectation that the backspaces in the input
will somehow be magically processed internally and only the resultant
string will be printed.  This may or may not happen depending on what
the optimisation decides needs to do to update the screen to match the
internal image of the terminal.  There may be all sorts of characters
emitted to update the "screen" image.

Also, erase and kill character processing is not done in cbreak mode
according to the curses standard.

On Wed, Apr 17, 2024 at 04:25:01PM +0000, 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: 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.
>  

We follow the Opengroup SUSv2 curses specification.  Well, we try.

>  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.
>  

This is the problem here, a pipe is not a terminal so you should not
expect termios behaviour.  If you really want to do this properly you
should communicate with the curses based application over a pty.

If you want to see an example of how this is done, have a like at the
libcurses automated test framework which is used to perform automated
tests on curses functions.

>  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.
>  

No, it should comply to the documented specification.

>   >>   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.
>  

Or, in reality, whatever the user sets using stty but also for curses
the terminfo definitions apply too.

>   > 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.
>  

And solve nothing as there is no guarantee that the termios settings are
the same.

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"