On 2024-01-20 20: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?
Coreutils' stty does stick to some standard: POSIX. POSIX doesn't specify a cbreak mode so it is an extension. (Perhaps one that didn't originate with the GNU stty?) The documentation says that it's a synonym for -icanon; and likewise the negation -cbreak is for icanon. icanon *does* come from POSIX, and cannot be changed, so what (I think) you're proposing is that cbreak should be something other than icanon. That obviously breaks scripts which rely on cbreak to be a synonym for icanon. stty could reasonably adopt a "cursescbreak" mode that is a combination of modes that correspond to the curses cbreak behavior. > 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 Yes, that's what happens when you make changes for the sake of word semantic consistencies with unrelated projects.
