GNU bug report logs - #79464
stty raw puts terminal in noncanonical mode unconditionally (non-XSI behavior)

Previous Next

To reply to this bug, email your comments to 79464 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Scott <jscott <at> posteo.net>
To: bug-coreutils <at> gnu.org
Subject: stty raw puts terminal in noncanonical mode unconditionally
 (non-XSI behavior)
Date: Wed, 17 Sep 2025 23:07:44 +0000

[Message part 1 (text/plain, inline)]

Hello,

When using and debugging GNSS receivers, it's typical to get data over a serial communications channel. The de facto standard format, known as NMEA-0183, sends records as lines of US-ASCII text. Thus it is convenient for me to have this terminal in canonical mode for the sake of reading lines but to otherwise not have the data transformed so as to depart from the protocol: don't mangle newline characters or do anything special with any control characters that may be perceived, for example.

The raw combination mode to stty (but not cfmakeraw()) is in the Single UNIX Specification under the XSI option. At https://pubs.opengroup.org/onlinepubs/9799919799/utilities/stty.html#tag_20_116_05_06 one finds
> [XSI]
> raw (-raw or cooked)
> Enable (disable) raw input and output. Raw mode shall be equivalent to setting:
> stty cs8 erase ^- kill ^- intr ^- \
>	quit ^- eof ^- eol ^- -post⃰ -inpck
> [/XSI]
[＊I do believe this is a mistake in the standard: "-post" should read "-opost". I'll file an issue on The Austin Group's bug tracker soon for that.]

The GNU version of stty does more; at stty.c:1600 one finds the following:
{
	/* Raw mode. */
	mode->c_iflag = 0;
	mode->c_oflag &= ~OPOST;
	mode->c_lflag &= ~(ISIG | ICANON
#ifdef XCASE
			| XCASE
#endif
		);
	mode->c_cc[VMIN] = 1;
	mode->c_cc[VTIME] = 0;
}

The GNU behavior is non-conforming, but it's also inconvenient for me in practice. BusyBox's stty, for comparison, doesn't have this quirk. The command-line help on my system (maybe older than what's in Git) says
> raw	same as -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -icanon -opost -isig -iuclc -ixany -imaxbel -xcase min 1 time 0
and that's quite the mouthful; I'm not sure this is actually true.

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.

[signature.asc (application/pgp-signature, inline)]

[smime.p7s (application/pkcs7-signature, attachment)]

Message #8 received at 79464 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: John Scott <jscott <at> posteo.net>, 79464 <at> debbugs.gnu.org
Subject: Re: bug#79464: stty raw puts terminal in noncanonical mode
 unconditionally (non-XSI behavior)
Date: Tue, 7 Oct 2025 23:00:23 +0100

On 18/09/2025 00:07, John Scott wrote:
> Hello,
> 
> When using and debugging GNSS receivers, it's typical to get data over a serial communications channel. The de facto standard format, known as NMEA-0183, sends records as lines of US-ASCII text. Thus it is convenient for me to have this terminal in canonical mode for the sake of reading lines but to otherwise not have the data transformed so as to depart from the protocol: don't mangle newline characters or do anything special with any control characters that may be perceived, for example.
> 
> The raw combination mode to stty (but not cfmakeraw()) is in the Single UNIX Specification under the XSI option. At https://pubs.opengroup.org/onlinepubs/9799919799/utilities/stty.html#tag_20_116_05_06 one finds
>> [XSI]
>> raw (-raw or cooked)
>> Enable (disable) raw input and output. Raw mode shall be equivalent to setting:
>> stty cs8 erase ^- kill ^- intr ^- \
>> 	quit ^- eof ^- eol ^- -post⃰ -inpck
>> [/XSI]
> [＊I do believe this is a mistake in the standard: "-post" should read "-opost". I'll file an issue on The Austin Group's bug tracker soon for that.]
> 
> The GNU version of stty does more; at stty.c:1600 one finds the following:
> {
> 	/* Raw mode. */
> 	mode->c_iflag = 0;
> 	mode->c_oflag &= ~OPOST;
> 	mode->c_lflag &= ~(ISIG | ICANON
> #ifdef XCASE
> 			| XCASE
> #endif
> 		);
> 	mode->c_cc[VMIN] = 1;
> 	mode->c_cc[VTIME] = 0;
> }
> 
> The GNU behavior is non-conforming, but it's also inconvenient for me in practice. BusyBox's stty, for comparison, doesn't have this quirk. The command-line help on my system (maybe older than what's in Git) says
>> raw	same as -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -icanon -opost -isig -iuclc -ixany -imaxbel -xcase min 1 time 0
> and that's quite the mouthful; I'm not sure this is actually true.
> 
> 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.

Also related to this is cfmakeraw() of which there is a good summary at:
https://github.com/mitogen-hq/mitogen/wiki/cfmakeraw-notes
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 ^- ?

Why exactly do you need icanon enabled?

It seems like you have non standard requirements
which may be best served with specific stty settings,
which you could save with `stty -g` and set as required?

thanks,
Padraig

Message #11 received at 79464 <at> debbugs.gnu.org (full text, mbox):

From: Martin D Kealey <martin <at> kurahaupo.gen.nz>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 79464 <at> debbugs.gnu.org, John Scott <jscott <at> posteo.net>
Subject: Re: bug#79464: stty raw puts terminal in noncanonical mode
 unconditionally (non-XSI behavior)
Date: Fri, 7 Nov 2025 08:18:06 +1000

[Message part 1 (text/plain, inline)]

On Wed, 8 Oct 2025 at 08:00, Pádraig Brady <P <at> draigbrady.com> 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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.