Re: Unset ICRNL in CBREAK mode in stty(1) following X/Open Curses

[Soumendra Ganguly]

Dear Pádraig,

Thank you for the excellent explanation. Specifically, "I.e. input _is_
sent character at a time rather than line at a time," is enlightening.

Kaz Kylheku gave a helpful response earlier, but I forgot to cc coreutils
in my response to him. He suggested that it might be acceptable to add a
"cursescbreak" option, but that is obviously entirely upto the maintainers.
I could try working on this if you like, and I had signed a set of
copyright assignment forms for FSF earlier for a glibc contribution, which
ended up not happening since I started working at a different university.
Therefore, I might have to do that again (is it required?).

Doing this might be useful for users who expect curses like behavior
without having to worry about *what
exactly* needs to be done to get curses like behavior (such as clearing
ICRNL).

Sincerely,
Soumendra

On Sun, Jan 21, 2024 at 3:02 PM Pádraig Brady <P@draigbrady.com> wrote:

> On 21/01/2024 04:01, Soumendra Ganguly wrote:
> > Respected maintainers,
> >
> > In X/Open Curses, Issue 7 (
> > https://pubs.opengroup.org/onlinepubs/9699909599/toc.pdf), the
> following is
> > mentioned about the cbreak mode:
> >
> > This mode achieves the same effect as non-canonical-mode, Case B input
> > processing (with
> > MIN set to 1 and *ICRNL cleared*) as specified in the XBD specification.
> >
> > For example, ncurses does this in NCURSES_SP_NAME(cbreak):
> >
> https://github.com/mirror/ncurses/blob/87c2c84cbd2332d6d94b12a1dcaf12ad1a51a938/ncurses/tinfo/lib_raw.c#L177
> >
> > My question is this: I understand that the standard linked above is NOT a
> > specification for stty but rather for curses, and therefore the Coreutils
> > implementation of stty need not follow it. *But*, would this be a welcome
> > change in stty for the sake of sticking to *some* standard? Or could this
> > potentially break lots of existing projects?
> >
> > ---------------------------------------------
> >
> > Some context: I had made some changes in the tty library of Python to
> make
> > it more standard compliant:
> https://github.com/python/cpython/pull/101832
> >
> > This is a part of a series of changes:
> > https://github.com/python/cpython/issues/85984
> >
> > The particular change of concern is that in `tty.setcbreak()`, I unset
> > ICRNL. Because of this change , some old behavior is broken:
> > https://github.com/python/cpython/issues/114328
> >
> > Sincerely,
> > Soumendra
>
> cbreak is a mode between raw and cooked.
> I.e. input _is_ sent character at a time rather than line at a time,
> though there is still some processing done on some input chars.
> Being somewhere between the raw/cooked extremes makes the cbreak
> "definition"
> somewhat fuzzy as you've seen.
>
> If I was implementing from scratch I _would_ have cbreak
> clear line oriented settings like icrnl.
>
> However given that the unix stty implementations (and python) agree
> that cbreak doesn't touch icrnl, I wouldn't change it at this stage.
> Also one generally has the control to easily set icrnl independently from
> cbreak,
> so it's not too onerous to do that where needed.
>
> thanks,
> Pádraig.
>