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

John Scott <[email protected]>
Newsgroups gmane.comp.gnu.core-utils.bugs
Message-ID <[email protected]>
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, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSiPzylvTnZ6xisfzWz9N0oYfTNugUCaMs/NwAKCRCz9N0oYfTN
ugNdAQDvOknBOf0rI6L9PztI32O6rirlWSR52b5dmi2gurNFlQEApAylA35H+ap9
YO8G8lRmKRBytHujWZ8Yvr9q/bD71QE=
=oqFw
-----END PGP SIGNATURE-----
smime.p7s (application/pkcs7-signature, 4.2 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.