On Wed, 8 Oct 2025 at 08:00, Pádraig Brady <[email protected]> wrote:
> Note that no platforms leave ICANON set with cfmakeraw which is > interesting. > It seems like ICANON is a higher level way to achieve the same as the > POSIX specified disabling of Ctrl char handling, i.e.: > erase ^- kill ^- intr ^- quit ^- eof ^- eol ^- ? I suspect that Busybox is the outlier; GNU seems closer both to the intent of the standard and to historical behaviour. On 18/09/2025 00:07, John Scott wrote: > In conclusion, I'd like the GNU stty raw mode to leave icanon alone, but > if this is seriously objectionable then guarding that behavior behind > POSIXLY_CORRECT would be an appreciated compromise. > Given that “stty raw” implies the equivalent of “eol ^-”, which should disable breaking the input into delimited lines, it's hard to see how one could tell whether ICANON is on or off without actually inspecting that flag. In other words, disabling ICANON is indeed “equivalent to” the stated changes. Except… OpenGroup says nothing about additional characters that may be interpreted including: discard, eol2, erase, lnext, rprnt, swtch, start, stop, & susp. And it doesn't mention changing flags such as icrnl, igncr, inlcr, and isig. Failing to set ALL control chars to ^- while leaving ICANON enabled, or leaving both ICANON and ICRNL enabled, would probably not achieve the "unprocessed but delimited" input that seems to be desired. Furthermore, if “stty raw” that *does* actually set all the control chars to ^-, the old values aren't saved anywhere, so “stty cooked” can't then fully restore them. So that “equivalent to” isn't just an escape hatch, it's an implementation necessity. Sounds like a case for a new option; perhaps "rare" (lightly cooked)? -Martin
