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