bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: raw() ignored while in getnstr()


From: Thomas Dickey
Subject: Re: raw() ignored while in getnstr()
Date: Sat, 15 May 2021 17:14:32 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

On Sat, May 15, 2021 at 11:10:17AM -0400, Thomas Dickey wrote:
> On Fri, May 14, 2021 at 11:24:59PM -0400, Bill Gray wrote:
> >    Not sure if this is a bug,  peculiarity,  or feature.
> > 
> >    At least on my Xubuntu 20.04 box,  raw() ensures that Ctrl-C is
> > not caught as an interrupt causing immediate shutdown.  The exception
> > is when we're in getnstr().  Run the following minimal example,  and
> > you can hit keys and get their ASCII values on the screen,  including
> > Ctrl-C,  with no shutdown.
> > 
> >    Hit 'q',  and the program asks you to enter some text,  using
> > getnstr().  At this point,  even though raw() is set,  Ctrl-C aborts.
> > This happens in xterm and the Linux console.
> > 
> >    PDCurses doesn't do this (raw() means raw(),  even in getnstr()).
> > Is there some reason ncurses behaves this way?
> 
> ncurses does this because it handles the left-cursor key (KEY_LEFT):
> 
>        The  user's  erase and kill characters are interpreted.  If keypad mode
>        is on for the window, KEY_LEFT and KEY_BACKSPACE  are  both  considered
>        equivalent to the user's kill character.
>  
> which agrees with the description here:
> 
>       https://pubs.opengroup.org/onlinepubs/7908799/xcurses/getnstr.html
> 
>       The user's erase and kill characters are interpreted, as well as any
>       special keys (such as function keys, home key, clear key, and so on).
> 
> The short answer is the special keys have gotten all of the attention in this
> area, and that because raw mode is associated with no timeout, which 
> interferes
> with interpreting special keys, it was never an issue.  (After all, X/Open
> says that erase (^H) and kill (^U) are interpreted, then why not the interrupt
> and quit characters).

now... I've made improvements in this area, but the handling of
raw (and cbreak) in wgetstr dates back to the original pcurses
in 1986.  The 4.3BSD curses library at that time didn't
have comparable behavior (it didn't override echo, raw or cbreak).

Solaris SVr4 curses evolved from both BSD curses and pdcurses:
+ Its wgetnstr tweaks echo, and does a check if raw is set,
  to decide whether to tweak cbreak.
+ Solars xpg4 curses tweaks echo and cbreak without paying attention to raw.

However, as I understand it, pdcurses also evolved from pcurses.
I see that its wgetnstr sets cbreak, but leaves raw alone.

Looking at my collection of pccurses/pdcurses snapshots,
I don't see raw/noraw in any of those wgetnstr's, going back to 1987.

There's no changelog for any of that, but I'd suppose that
someone working on pccurses at the beginning changed it to
be more like BSD curses in this detail.

Just removing the tweak for raw from ncurses' wgetnstr doesn't
prevent ^C from stopping the program.  Removing the cbreak call
does that (I understand why that happens, but haven't decided
whether it's the right way to address this difference -- for the
moment I'll just document the difference).

p.s: the up=^C, etc., are due to your example using '%c' to print keycodes
     rather than translating those using unctrl and/or keyname.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]