NetBSD Problem Report #57867
From www@netbsd.org Sat Jan 20 15:13:58 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id ADD221A9239
for <gnats-bugs@gnats.NetBSD.org>; Sat, 20 Jan 2024 15:13:58 +0000 (UTC)
Message-Id: <20240120151357.4B6201A923A@mollari.NetBSD.org>
Date: Sat, 20 Jan 2024 15:13:57 +0000 (UTC)
From: achowe@snert.com
Reply-To: achowe@snert.com
To: gnats-bugs@NetBSD.org
Subject: Why does cbreak or raw affect terminal output differently?
X-Send-Pr-Version: www-1.0
>Number: 57867
>Category: lib
>Synopsis: Why does cbreak or raw affect terminal output differently?
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: lib-bug-people
>State: closed
>Class: support
>Submitter-Id: net
>Arrival-Date: Sat Jan 20 15:15:00 +0000 2024
>Closed-Date: Fri Feb 23 06:03:56 +0000 2024
>Last-Modified: Fri Feb 23 06:03:56 +0000 2024
>Originator: Anthony Howe
>Release: 9.3
>Organization:
>Environment:
NetBSD elf.snert.com 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
In an effort to create a basic regression test suite for a program by capturing screen output for a given limited `TERM` (ansi-mini, vt52, adm3a), I came across an oddity that I have not yet understood (even after looking at `libcurses/tty.c`).
Q: Why does `cbreak()` generate slightly different terminal output from `raw()` for the same `TERM`?
I figured it something with respect to `OPOST`, but have yet to grok what is happening and how I might generate a minimal custom `TERM` that forces consistent output regardless of `cbreak()` or `raw()` (noecho() and nl()).
Thank you for your time and attention.
>How-To-Repeat:
Currently do not have a simple demonstration of above.
>Fix:
>Release-Note:
>Audit-Trail:
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: blymn@netbsd.org
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Mon, 22 Jan 2024 07:45:37 +0000 (UTC)
On Sat, 20 Jan 2024, achowe@snert.com wrote:
> Q: Why does `cbreak()` generate slightly different terminal output from `raw()` for the same `TERM`?
>
It shouldn't. I think this is a bug which has also been fixed in 10.x:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55931
https://github.com/NetBSD/src/commit/d08b4150a2bca36a1a004613dfdb10d71ed144b7
CC-ing blymn@ (curses maintainer) to see if he says any different.
-RVP
From: Brett Lymn <blymn@internode.on.net>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
achowe@snert.com
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Wed, 24 Jan 2024 08:02:54 +1030
On Mon, Jan 22, 2024 at 07:50:02AM +0000, RVP wrote:
>
> It shouldn't. I think this is a bug which has also been fixed in 10.x:
>
It should, see:
https://pubs.opengroup.org/onlinepubs/7908799/xcurses/intov.html#tag_001_005_002
the termios settings are different between raw and cbreak, see the function
_cursesi_gettmode in tty.c which defines the mode.
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55931
No, that was an implicit assumption that CUD1 was set to a newline character which would
result in an implicit carriage return being sent and result in the cursor moving to the
beginning of the next line. Some terminals did not do this which broke the display.
Also, a couple of things:
1) This isn't really a bug per se, it probably would have been better to ask on one of the
mailing lists.
2) If you are trying to create some sort of capture for curses output the have a look in the
automated test framework for the libcurses test which do exactly this already.
--
Brett Lymn
--
Sent from my NetBSD device.
"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: blymn@netbsd.org
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Wed, 24 Jan 2024 00:57:27 +0000 (UTC)
On Tue, 23 Jan 2024, Brett Lymn wrote:
> It should, see:
>
> https://pubs.opengroup.org/onlinepubs/7908799/xcurses/intov.html#tag_001_005_002
>
> the termios settings are different between raw and cbreak, see the function
> _cursesi_gettmode in tty.c which defines the mode.
>
Thanks for the link, but, that seems to be talking about curses
behaviour re: input mode; but, for output, does curses behave
differently between cbreak() and raw()? If yes, what are the
differences in behaviour?
-RVP
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Wed, 24 Jan 2024 05:00:56 +0300
On Wed, Jan 24, 2024 at 01:00:04 +0000, RVP wrote:
> behaviour re: input mode; but, for output, does curses behave
> differently between cbreak() and raw()? If yes, what are the
> differences in behaviour?
It was not clear from the original question if input was involved,
presumably yes, so there may be differences.
I can't quite remember all the nuances, so when I need to, I check
this table from SCO UNIX Development System, User Interface Guide:
Input Characters
Options Interpreted Uninterpreted
Normal interrupt, quit
'out of ETI stripping
state' <CR> to <NL>
echoing
erase, kill
EOF
Normal echoing (simulated) All else undefined.
ETI 'start up
state'
cbreak() interrupt, quit erase, kill
and echo() stripping EOF
echoing
cbreak() interrupt, quit echoing
and noecho() stripping erase, kill
EOF
nocbreak() break, quit echoing
and noecho() stripping
erase, kill
EOF
nocbreak() See caution below.
and echo()
nl() <CR> to <NL>
nonl() <CR> to <NL>
raw() break, quit
(instead of stripping
cbreak())
Figure 2-1 Input option settings for ETI programs
Every curses program accepting input should set some input options
because the default settings cannot be guaranteed to be consistent for
all terminals. The combination of noecho() and cbreak() is most
common in interactive screen management programs. noecho can prevent
characters from being echoed at the current character position.
Instead the program might have them echo at the bottom of the screen
instead. When noecho() turns off echoing, normal erase and kill
processing is still on. The routine cbreak() can cause these
characters to be uninterpreted.
Do not use the combination of nocbreak() and echo(). If you use it in
a program and also use getch(), the program will go in and out of
cbreak() mode to get each character. Depending on the state of the
tty driver when each character is typed, the program may produce
undesirable output. To prevent the terminal from being set
incorrectly, routines could be written that contain all the desired
settings. Suggestions are provided in the section "Ensuring the
correct terminal settings" later in this chapter.
-uwe
From: Anthony Howe <achowe@snert.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Wed, 24 Jan 2024 09:48:11 -0500
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------lpvA5sks2vJ5trE3FHG3sDDL
Content-Type: multipart/mixed; boundary="------------L7H0oVQotdjxa0JcR0qa5NU0";
protected-headers="v1"
From: Anthony Howe <achowe@snert.com>
To: gnats-bugs@netbsd.org
Message-ID: <9e4d3e1e-10e3-4832-9650-82a192493f22@snert.com>
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
References: <pr-lib-57867@gnats.netbsd.org>
<20240120151357.4B6201A923A@mollari.NetBSD.org>
<20240122075002.348501A9239@mollari.NetBSD.org>
<ZbAwhhxNshp51g4I@internode.on.net>
In-Reply-To: <ZbAwhhxNshp51g4I@internode.on.net>
--------------L7H0oVQotdjxa0JcR0qa5NU0
Content-Type: multipart/mixed; boundary="------------LhUad6VlDnp3N8hZ2QUJbH0I"
--------------LhUad6VlDnp3N8hZ2QUJbH0I
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
T24gMjAyNC0wMS0yMyAxNjozMiwgQnJldHQgTHltbiB3cm90ZToNCj4gT24gTW9uLCBKYW4g
MjIsIDIwMjQgYXQgMDc6NTA6MDJBTSArMDAwMCwgUlZQIHdyb3RlOg0KDQo+IEl0IHNob3Vs
ZCwgc2VlOg0KPiANCj4gaHR0cHM6Ly9wdWJzLm9wZW5ncm91cC5vcmcvb25saW5lcHVicy83
OTA4Nzk5L3hjdXJzZXMvaW50b3YuaHRtbCN0YWdfMDAxXzAwNV8wMDINCj4gDQo+IHRoZSB0
ZXJtaW9zIHNldHRpbmdzIGFyZSBkaWZmZXJlbnQgYmV0d2VlbiByYXcgYW5kIGNicmVhaywg
c2VlIHRoZSBmdW5jdGlvbg0KPiBfY3Vyc2VzaV9nZXR0bW9kZSBpbiB0dHkuYyB3aGljaCBk
ZWZpbmVzIHRoZSBtb2RlLg0KDQpUaGUgU1VTIEN1cnNlcyBJc3N1ZSA3IHRhbGtzIGFib3V0
IGNicmVhaygpLCByYXcoKSwgbmwoKSBhcyBmdW5jdGlvbnMgYWZmZWN0aW5nIA0KaW5wdXQg
b25seSAobm8gbWVudGlvbiBhYm91dCBvdXRwdXQpLiAgWWV0IHR0eS5jLCByYXcoKSwgZGlz
YWJsZXMgYE9QT1NUYCB0aGF0IA0KaW5mbHVlbmNlcyBvdXRwdXQgYW5kIGNicmVhaygpIGxl
YXZlcyB3aGF0IGV2ZXIgdGhlIHRlcm1pb3Mgb2ZsYWcgaGFzIHNldCBieSBzdHR5Lg0KDQpo
dHRwczovL3B1YnMub3Blbmdyb3VwLm9yZy9vbmxpbmVwdWJzLzc5MDg3OTkveGN1cnNlcy9j
YnJlYWsuaHRtbA0KaHR0cHM6Ly9wdWJzLm9wZW5ncm91cC5vcmcvb25saW5lcHVicy83OTA4
Nzk5L3hjdXJzZXMvbm9ubC5odG1sDQoNCldoZW4gSSB3YXMgd2l0aCBNS1MgbWFpbnRhaW5p
bmcgdGhlaXIgQ3Vyc2VzIGFuZCBiYWxsb3RpbmcgWG9wZW4gYXQgdGhlIHRpbWUsIEkgDQpm
b3VuZCBoaXN0b3JpY2FsIEN1cnNlcyBiZWhhdmlvdXIgKHdoaWNoIHRvdWNoZXMgaW5wdXQv
b3V0cHV0IHRlcm1pbmFsIA0KYmVoYXZpb3VyKSB0byBjb25mbGljdCB3aXRoIFhPcGVuIGRy
YWZ0cyBhdCB0aGUgdGltZSB3aGljaCBvdmVybG9vayBob3cgdGhvc2UgDQpmdW5jdGlvbnMg
YWxzbyBhZmZlY3QgdGVybWluYWwgb3V0cHV0Lg0KDQo+IEFsc28sIGEgY291cGxlIG9mIHRo
aW5nczoNCj4gDQo+IDEpIFRoaXMgaXNuJ3QgcmVhbGx5IGEgYnVnIHBlciBzZSwgaXQgcHJv
YmFibHkgd291bGQgaGF2ZSBiZWVuIGJldHRlciB0byBhc2sgb24gb25lIG9mIHRoZQ0KPiBt
YWlsaW5nIGxpc3RzLg0KDQpXZWxsIEkgZmlsZWQgdGhpcyBub3QgYXMgYSBidWcsIGJ1dCBh
cyBhIGBzdXBwb3J0YCBxdWVzdGlvbiwgd2hpY2ggSSBhc3N1bWUgdGhpcyANCmZlbGwgdW5k
ZXIgaW4gY2FzZSBpdCBlbGV2YXRlZCB0byBhIGJ1Zy4NCg0KLS0gDQpBbnRob255IEMgSG93
ZQ0KYWNob3dlQHNuZXJ0LmNvbSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
QmFycmljYWRlTVggJiBNaWx0ZXJzDQpodHRwOi8vbmFub3plbi5zbmVydC5jb20vICAgICAg
ICAgICAgICAgICAgICAgICAgICBodHRwOi8vc29mdHdhcmUuc25lcnQuY29tLw0KDQo=
--------------LhUad6VlDnp3N8hZ2QUJbH0I
Content-Type: application/pgp-keys; name="OpenPGP_0xA550323B6ED894D7.asc"
Content-Disposition: attachment; filename="OpenPGP_0xA550323B6ED894D7.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP PUBLIC KEY BLOCK-----
xsBNBE/XqKcBCAC6b0/lhDp8to/wA+Na+vC4t8EaPzkwZAVSeFuYFkGms8lkYX7i
LOmZRjov72F1441fLaIqGzAkLz80YxHcF7R3EDg6SmxFyHpEAT4fDfO2g7r6zlI8
82rsZKTU1eQ2EsKXSAdNzLf5d6X5zfaGo1XO0qN9bFFLWrgFWuFksr/dqrr2lcd4
WEUT+q8dKw2zf1VbPw4bkboJ2vKwn0bavjPXTrrB5mUvfG4r/Ejtkv+3CdEjN9zf
5Ln78nnPcsI/bX342485bXpVIixI9ByUr0qvkNyajBvahgC248OsZs3HlXrBuAJG
QAzuUnLGIHA3wwxbBAADYW0bHkTvsrliQPw5ABEBAAHNI0FudGhvbnkgSG93ZSA8
YWNob3dlQHNuZXJ0c29mdC5jb20+wsB5BBMBCAAjBQJXfs2VAhsjBwsJCAcDAgEG
FQgCCQoLBBYCAwECHgECF4AACgkQpVAyO27YlNfbTAf/XecVUy2OOJmzpARO28ta
v6HIEY+m7eFzKytksgfLyKClwJfT7WfrvJgYkNvx4L3e99i7CHd4UiUXUxDJzpFc
wYcZ9mAL9AYIGOUAHAuYFRJgfRy9y6scUNpGdefu02uAHRpvgeNtIfvqhyPNY5Ar
WElcPawYb3b8osV0BUHaqeav2N4LAEgRWRhY5hMe3cpEgUdAVhyGOzA+coadsX2U
Rinu+FPTSQgQ1pRFTOI70hgVpImcOcRoEiFgLaV5Vy0y/Z1ELIMy9j5rNQDMKUAE
TgaLt8pieOlvOD+P0awEubtw+d/8A4461IOXPmjw/NnWTg+kpfTxTT33OGuURzwp
Ss0fQW50aG9ueSBIb3dlIDxhY2hvd2VAc25lcnQuY29tPsLAewQTAQIAJQIbIwYL
CQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAld+zboCGQEACgkQpVAyO27YlNfCCAf9
HpkpFUuGgoKsUIQf0KQbk+NdyC2X8Tq93LkgXji17SiBDZdOIMqwqNXoJsW5sfAe
TMS91LSABmMpprSK6TOrwF6wXsDSIZPUeaPEHwQmvpPqxzMKLAgRHqBkcPs+t/71
UOIeZmItQknEhrhlHdvjoQIQfH/EA0d7BYUJNKrs8Fb1EKu0TH8ZHJ2bin+0mx8c
/FTE3jXQWVzKeU209Ge+qQ+/sVxB02uyLDFqMhdatJ1o0qQOo/WEMp0MkY4ZOOty
m1crMS+KYxJLoxlTpMd8IKFR7VRfDNWYim2DVOtm4rm6ENZhyLEg5ysbsMM80wrC
2z5RtW6DQA+Tv4h5whJsbsLAeAQTAQIAIgIbIwYLCQgHAwIGFQgCCQoLBBYCAwEC
HgECF4AFAld9jg4ACgkQpVAyO27YlNesNAgAtUmGriWaVsM9pV5ToJMo+kpFHeFu
Pbj1ot6VsP1gmR9+6xxurA8VBm6BlSmZ7NMYwENAGJ2vyyOXCRtPUJE+RG7v3vIy
xniHXB8+lBf8z0xnDozAItQ9nSNXmJGobCHRAeCqIP3AXd2tlacO3G49aaWRSJ6l
2t28SOzrMKuvSD5pkeM++LQN2TxXLMSQfthBDcIimgiQFIIDXSvnr9RYdV4CRtWA
L6SdWx9QFAY9ushf7rJb8CXV9IcytlNZP8fPOpDadbBOpERcv+giOyxZY+HM/qUA
7pz8AvGWVdI3/xxieTjkRQuh+h7EihJuhSloI7/C9ghcYMS4wVOhKQD8m8LAfgQT
AQIAKAUCT9eopwIbIwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ
pVAyO27YlNcvVgf/UQU7HUOZ6+9VS82B75dBm8bFocuAqh/rYY1HxOF7ugrtElO7
rBmfA63mGz2CJQQUWnfSj/YP9efnwr2SxXJH6ygaew7UIZtzv4pzO4SotFl4VwCw
S45kEXgKdCazisjeqVbBWYuO1g3gOB0u6KblKBewVNp7qDxmA6ASMKvC7TG3PtBc
vvb9XY+fmqglXqDE/enyrBr7mEr+jnQqv0mMFz77On2UCKSKg4SmBoVeCM+dA6do
jByagXaNQ0D+XpsBz03QMawcBX/aZFR5d+4HaBA7M0DzzfZjvWfdmuqq73M5rBej
Rr7yLvF8NYrSH2R7YHx+oWU9i5s8Q/dncV0KLdHQrNCqARAAAQEAAAAAAAAAAAAA
AAD/2P/gABBKRklGAAEBAQEsASwAAP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAf/CABEIADAAMAMBEQACEQEDEQH/xAAbAAEBAAIDAQAA
AAAAAAAAAAAIBwUJAQQGCv/EABoBAAMBAQEBAAAAAAAAAAAAAAMEBQYCBwD/2gAM
AwEAAhADEAAAARBmKsWbE18RsaN2a50CIZ4WnZUHkW4lUjV+bM1YsNPL5/Wx1mz3
n7dLeHhrCXc75UC7wNv4TPYHd2BuunqPB8FxT2Q6XtL527sHuawWpeqpivKY2F01
vm00XmLLy+oVbZ8nTGc1TbS6Jv/EAB8QAAIDAQACAwEAAAAAAAAAAAMEAgUGAQAH
EhMVFP/aAAgBAQABBQJumXZos7SddslFVw8UCL5VSS0OxTWmo21+fXZvvyfbdMEa
2ks0pZbV1VnIH85KnY+s3c7T1S0QQTEFdVNXSG7Z01bUvY/QHIjsdre8RCMsBVY+
T8UWV4HXEXL56xohtmsW3rIsZ/Z5SDkUtlbDz9X+g1cQ9cp8DTxLGUc7cBeXoXIB
Bpn1SJJVbwnMbfI12a//xAA2EQABAgUCAwQIBQUAAAAAAAABAhEDBBIhMQBBEyJh
BVFxgSMkMkKRobHwBnLB0eEUM1Jigv/aAAgBAwEBPwGW7Em48p/Ww6aV8ShLmpYQ
plEe6L7WdvhJShizFCwfRk8RODyliNt9IhwwlgkBrYcsbWb55b6CGgMCwcZ+fj9M
aI2AB32b4X+R8LaiQ00rsBylywN2/Lt5a7NjJHYkrFsvhBcIDCkr40QqdhgujJFi
GbJkj63OR1JKUqiqTvykrfm6dfdLPYkiZiRkgcL22YZZPebHzAc+Z0qbmIY9IB7T
bsB45+dxtvqD2iFFwb2cXfx/TP8AK46VhVJwkvjcZYAHfq+vwn2tBnhOdls9NMym
osKQeHFTl3JEIjmsQ7alkJQZgMD61Fva7nIGOn22o0pFMdIeMiXEM/2lAMvPNbil
JwhlBCQMAamZSaAMSXjBdILw41kkuGTUkGN+Z1fHGpeBF4PEmIKUxL1UqQ/jysA+
UEsQbFJZyiHSkrSpRhqSoUrDK8CCBjvFsEWbUlT2fMCJ2elEGMlPNHTzKCF2MMkk
1V/4q5W5mdnl1r98irKy+V5UQA1P/I3a2kueb2wphScdC2QfK9raiQC9gU2uTfPx
P8aRJvVUVKqBSlwoJfrYMH2L922pqRhwpcQk1JUE81ESI4Jb2TWoBhZNma2Lal4S
UciN4mSSSXO5P2NJCeIosLE4vt+22/1grS24I73Af738r6XESXCbq3PQDH6DrpBC
oSFJcVpqN3ILOxtbuyf3mEgpUon2UWbcs2+/QDroW8c6lZoRUuTzkCrD9x6ZYg6X
MUgcwZ+br348NQ5xalik0jJswA8+9gO7UObiQl1VGgkcQC4bmHe9QyCA7f66jz8J
dJKlejK1JSLBTppBUWBNLlvOxtr/xAAuEQACAQQBAwMCBgIDAAAAAAABAhEDEiEx
BAAiQQUTURRhIzIzUmJxQpGhsdH/2gAIAQIBAT8BPqdOlyPbcj9QXZ0bc/eYZSDG
jkgdeoc0cfi+7TYTVgU32stkNppEZ1GpPQeozuzPe2fcJJ7iAJkCSP4EW+bjHVP3
NyYwDklAw1oHAODjPn5FIEaM5zmVLCNgAGB8eVAzvpXPbnRXUnUSAT8/9R53W4/1
HPq02tI/OjvLQLFWPtb39m2wZhbevUAV43C4wIZ1RWxJLhcdmRme4S418jriU1Z2
ar20m8kqjTrtFgMd0XHQ7hHVPi0b1CEEGFWTEgzpguCxK3RiMMMnr6UlosAjR347
fmVycyd6Hj2SHXVzR9pPmT3HesLHjyOvWPTq3Ap0ucJVg9hgeGDETc0RF04bxJYg
Ryapf6eC0ihTpgyREAnvJZLe7RVVbtzBEHivRWiWejSrcq4gCqlUlgMAqaVRaRqb
LFriwjeeuE3GrWe5QFPvWfbYmoqzDNY7qpZVki7uiIbMjmCnScrQrNgzLXssGIAv
WTlYaMdyxmbRySxWkwAqLbMveCN3XL2mR2nZBkHI6qtX59I/XOWoSLKKKtJXdRuE
Vf0+2agN5LFcCeuUAHYLFtxsl/ypoKBqBjJa7uyTjqmwqLTVoX217WWmocI1R6hL
G38Zrnb23a5wsLcKaKgRUw12I7V+8eREQfEyw3PXKrgWqLABvK3kjBgMGzmc2xHn
A64VZ63IaofbeSv5qVPxkTaoOSLjgElyZ65NZ6n4j5hDgKqgQGaAoA/v5/vfTZOG
tFlxWQ8HAuJi0mcxsYhR1x6LXo2QJxiQ8sW/aYUScwR5AGIH4Sy2V0oEXRMQoQEz
mf4gA4iTXpmo5YuIDsLVEY0AxbJ/cZMd2iCY9Po2AQvY3gYP/ED48RHz4bIjxkf+
9V+J7NUC02liBgW51tltGf8AEYjOAAOHxwdsGN0AWsoGAPkwuwPkxGDPTcZBTDNl
iYAOh51An7YWMSD5PprVAVHtswBZZERuO4HRlpgAEk2yQD1wuDUpo1O1RcB3MdDJ
MAGTnG/99f/EADUQAAIBAwMBBAYKAwEAAAAAAAECAwQREgATITEFIkFhFCMyQlFx
FSQzUlOBkbHR8ENiocH/2gAIAQEABj8C245l9J24mSEU/dRB9neYXJZniKlVVysZ
yub4jYnUIKYtvIw5yj7pW3z66ULDFYcWwW3h5a+wjt5xL/Gkb0eDk/hL/H7jUxNJ
APqs1vVR/hP5eOoBskG0Ej7fGRwGAPUcncB69W8ddq9oYERyVDRnLqhdiylgLgfc
Y3svc8LkWpY9yYnqbkKPPz+ekarpVaPm9sgBb3v0/wBQOb9DqJWlSnfjuu4HPw5/
ttTYsr/VZxwb/wCFv74eWuy63tOWCenrl2GWnZ2KT7K1FMMxi1+7Mx7qcIRZsuKx
HUZTVdRLIpWy3k68H3CPdYm3TpqUUcVK1S5DA1tJFW2QHhKc1BkWBYyl3UxXkWXB
ZViTZMMcCUFVC1SgropKWET+ibgE4pRMfRM9vPbMqYgstuLgqu3tkRRO9ZSiaFd7
D1nqy2AEM4ZWjWG8sLRTIy3lhiq6QPvvHTSd+E7ibZiLB1I6ZcXVgHQ5JIodWGoP
pbtbtHtKeRI2paCoqp2pYnCFBNsq8SJiCURIohclgGAudU6TNlMsEQnI8ZgiiQ/I
yZHnw1EGIGHAZVANsixDFLZ95jy3ex4viFAEghGVrXA62/bQhSNU+/jjmw8eb5f+
+eu0e0KmaszNPVMrJW1UWREUr3mEcyLPk3LpLmG5Hw1RS1UxaaWBI+cbKOTGtlAC
4XTj3WU+PJLeOXX89IB01JVSxtMUjJjgT2nf5ngD4seLa+kJ9td7BvRksRAr84Ze
LL7xsO9fw1Wyont0VTk3wBhf/mo2z5QHHm9v3ta/w5+I66UmRFYWyBZeCR8/vg6L
xPG0vk6XC8Anr+X6a25KqEySd0qZUZuTbm7d3jy6frppezaqHZJG7TvOoSSM8dCc
VdTYq3F/ZJtfVbFJJTmoqKN0tvpdSImz6mwBuL256W8df//EACEQAQEBAAMAAgID
AQAAAAAAAAERIQAxQVFhcZGx0fHh/9oACAEBAAE/IVYtxnETTBORvxJTrWyqhHcy
vNrTmETDWhCn+nPd59gzE77Y8+Oj+OLFj2Vij7v8cIl9VBoggMwHyhonI4l6KUZO
JILpSDswjpQBAYVIDhIjYoh9vePq9nrdH1YqBhWjsI3oKsh65C8GEqBnYTVye7uX
Z779QHG4lAjr1QPkFLgTN4PpGzgoNnUQC6A8jkjDZTgS0B44jBNEUgS/eITPLnLp
PQZjjaXDwHwZiLXQoxyPSErXoGmQsrEsS9KPssZ8EqmbxGYRh2HzuBYjnqReUf79
xBK6x/HLjmft8UmGJPUcVs9hmto5r2EOFraBCXWsI7kwLwqwVcwta/v/AL7wy6Ho
NAT+uvj2u9dw0+YKD3yD7Ywzz/QGQKZCRkY5ssoNpIf6lenip+eIGJOwDnbAkcE6
rzrU3vG9/UvAwJix9AFGr4FexOfFp7Q5pFKCvTohUZfYLd0ilIjwRJAXSceljSwr
HP/aAAwDAQACAAMAAAAQJS9EPMqoP7A6cfBooF//xAAbEQEBAQEBAQEBAAAAAAAA
AAABESExAEFRYf/aAAgBAwEBPxCE1YuioW8MUFSsPEZghOgorBy2Qr8KLzk2AA1U
NKRLqyeBE5DNZgLpxCqUYhfCspBUk4BEgdV0IoQItRVCKV2NsoFMNmphHPU8sUe5
RqHwK0oVxvRNJFrWD6iNKggPZUCWiYSlEjU4w3AtRgqBtKKJnjQLpAIpYXQQbgx+
zxWNdLYBjA0xAlVQfA6SjWIT4EwVAl8pwqYQzIcElI6wSnhID4Ls0MicEICqti2g
F0y8lDAbr2OrQGQzgZyoYCz5bwqjc68rPBcXS8HoyHWYm4qcCiB46aqpZlCuooBE
KDxOFimccoCAqiqDuOdFDIB4hothQ1cp4BuSAUZokQvBzQ+K4vZDU2IWwOAx4/CB
DGkVKgDAsGQj4gyVhXVacCEysNUnlbRFqCgQcjBsIDKBPCiZcBp1AxWBoJEA31CC
q50IAVSECIbvlvaiVHpiumShnQHt6ZX9bc/H53vS98cZoKExtSEChStpHzlJkBRO
GALEECv3nK0WoqV+UuhNWok9Q22lXRFd34uFYPbYoDQFALQ8XSCP/8QAGxEBAQEB
AQEBAQAAAAAAAAAAAREhADFBYXH/2gAIAQIBAT8Qy7opBeg+ROCQQzgLaHKAwgEC
R0gBUFchZIytaAMqt1V0HU1UKAQEBaFG3hhEQJQGg9SLKEAb5CWGpgqhAJQCKiVO
2+nNWDhoBQ1YViJecCGh0qhHwiPr/QiEihQiCg6IjyAJhKzlIPklQFohsHqAgKKq
DCJVQztQhRM+iUOyiMh6pX4JldIAhHE7QuNqlCQe2QUuCNPiSH8GmvkjyD4q7cUK
psGBoFWV8FgBP54RZsFuIo8AWCYKrBvIM1GcC5SMswI4AUHlBhVoBAoCyxoaEqF8
fLNCkFSBEh8FGeY0ogJAgEiH6D04VDEuICktAKaiwBuwFIJCOm+F0iI3VMYQSAK2
l01XXEiqtIiKBIE6IlBYhFCAoksuMYiQRPDBlLKJGg4chCoS5jM4wgSwJUFAliOA
dDBAQBVXxqPifaTgotRD5ETGnjG+6w+mXUVQeBpEALshHAEWiDbKAmJSS6OxiZkl
NcYBigKhccSlW9qgWJIsA4jIA54aEiXguBRDn//EABsQAQEBAQEAAwAAAAAAAAAA
AAERIQAxQWFx/9oACAEBAAE/EKlpGOeW1TWfkhtxFk88qlAyoIhnioGq9iwSExhS
XzAwq+BwOJUUovIwoFvNoVAAEtbg36DmEIJA1QpLSbBRBDBJmjH8MXD9G6jCecSX
zKFSm6EgEEEWhY4zmDyWaxJspNwNoFrWSOql60DWlKFCQlNa93AJwDthFFRCAA67
ORm0KIKF5ZFJ3YcBcFdJNvMMSWuyX6jQYfiBoWkJ++f4gcVKsGEGLK6wzA3UHhch
lqA04qqY0TSt40ExGD1BgUTLP4NPlKedW1KGStGKX4Z6TEKiYY2iUc4CumOWf0ho
EV1mQezRlj4JNnKbAV0wLPqqpcSDYXhACWOCJS/MCihI4ClGwiC7dgVlrPYLr6D8
KDzYEYIXBANBAoExtRKlLmLpSbEuAAVcXEtKCY73ywCAigLfSjNENrOF0J0iz+F0
IpZnAGI4B0XQONWFAACXklvJAALNVKa3L//ZwsB5BBMBCAAjBQJXfs1rAhsjBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQpVAyO27YlNcO4Qf+KSTvjya/GPzO
1ckCQRRsU782qIIUHSq+/BiDpdj4Pm3cbJWP20lj3xLRuL/4xYWgNdHxW5RKs2Kx
KZ9fd/lHcCvDbpmDgd2KLoadyHgFattuiqJudrrtcQHoWHpXCarb2mPy/06gKONP
6xHnBO8paJ6h73gv23+x1L+ds60Nm1spBBBJ1Tz54iOEGwDFDywWeA+8LETdmLCr
OqiiOIbrL8Z6Ee/nXhyYILivg2wZBBKvcZnFTs9XKW3cnca0QqK1xrTb5Tt+yeIj
dmmKYbxHLVqkapaL4cnrYXccvXiHE2sFsMxYcLzi7BV2jNpz7ngwwKCmfi7Z0cHE
GUzGNmiqTs7ATQRP16inAQgA0d7suJR9N4Y/Nj/u82UXIrSxZQIdXRhlC7LyEo1a
jABgDCS08YgN2KtDmj4/j3uubtaIo9myearnJYd2AtCmPiCvggIX1T7Xwz1QwmOg
t4A34wx2KfmNJmeIy1E4PSTSi6Ok2RTLPGz3vJfEZU2Hq++HUeUqE9OF0GQjuvG7
/NtaeUsJHIxTr5Y8n1w6SU2IXXFadaUHRDud5gq/b+2w4V8Ld+8JITR4Vf7w9Cou
+PefpAm44yglnfFAlO/XAEDD4rnb7hfHswGyPdb2Dxs7pgcgHkG1vYBCiwrF08x8
AZd012zqfeOeF1hTVM4DmUxwwmf/4xJea8v37uSoqA5Y3wARAQABwsBfBBgBAgAJ
AhsMBQJXfY4UAAoJEKVQMjtu2JTXxdsH/3vmB5xVCfoEY777bt6dNABgqWV6Ef9i
taOCZwQXPY6d2gjdLbhvrbk1Dc4wq1IOX+CQVM1fR5s2fpz7VLYTf2jxocsm/a+T
2uqvdaYy0SbE12GqdrE/sQ4ustmPqpBP75HrZPhx6fD3NUMAo+kbds15jYK07Ow0
ixjPkGUM54CuSNxr+7v7dvFUqn7auUgNfNDluXR7nsDimyu3Ie/r2Klo/OVJ2HTn
GoYYcECO7PR3bNYboHcVs1eoz2hGV/UXyWO7NEy/XUbnXJgrcWC+73AgWzDDD7YV
C+94tQOafyjOFIB1+slpM8OHCMkvg+gPQ3rKkJnzoLEmIWSt8dRh/GPCwGUEGAEC
AA8FAk/XqKcCGwwFCQlmAYAACgkQpVAyO27YlNdrgwgAk77uirp8bgJCLaPpljP0
4diPp7MB8tM4eVKg5DEy5mljBD1MHeA+K/oPdzRyvVudr5FVvgRmgt+KyAcjHlho
H0Tg0mr2BPN8uNFjHfg0/YxU1MaJH4fBcC4Exf/yfRwTnRMQpbCF4E/6+LnlO5mw
kRBkHTi/aWj2v2gy3cbOIGPNXrEnfLE9noFX5KrQwSSf5bEv7cj+E//HTmoLTpK/
YwgXQiq15xj2fS57wYJDAQJe7eApi06X47wsDHwhcAW/80IcADJHOsOt2TcOdhKm
r1W/k7XyC7Vx4CvOrQMp8oVtSpBgOkelBKDP1taUAJLcYJ42kGzbAE/6sEsfQl07
iQ=3D=3D
=3DW6M6
-----END PGP PUBLIC KEY BLOCK-----
--------------LhUad6VlDnp3N8hZ2QUJbH0I--
--------------L7H0oVQotdjxa0JcR0qa5NU0--
--------------lpvA5sks2vJ5trE3FHG3sDDL
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEE+yYE6CVEuMOhbTT+pVAyO27YlNcFAmWxIysFAwAAAAAACgkQpVAyO27YlNfP
KQgAufMKWtFBGWji8r2sKcokMigNsdpUzOfrpdba5/a14GBCXu6xH3aGZ3xYAJmAWaBFCHCyV9Vi
u8uuhVRUYzwZvpsQ9M30+LXTSwJYGuFVCJTCXYiW6ejIRDgx6KPi0ORDYDNO6bHCxb74FZ7gGx0T
nqPMx0vGC0Ae4wx6JIuP1C2bMuqg3MrSDsyYPppZlnip1FMQVeBObjqhpLv1okyyOfcAj09TxFRT
LeLpgF5oDbum/7lRq+OzkauI98UPa5eIAMF2MV1K7yLRFyZEJOOpkBkkFO8jSXrKqoe/xx5iPQGO
sEWsxaOIV8Mlz67LlEh9fy+zH2N/M7nNAAD9U0yK3g==
=BLPX
-----END PGP SIGNATURE-----
--------------lpvA5sks2vJ5trE3FHG3sDDL--
From: Anthony Howe <achowe@snert.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Wed, 24 Jan 2024 09:53:10 -0500
On 2024-01-23 16:32, Brett Lymn wrote:
> On Mon, Jan 22, 2024 at 07:50:02AM +0000, RVP wrote:
> It should, see:
>
> https://pubs.opengroup.org/onlinepubs/7908799/xcurses/intov.html#tag_001_005_002
>
> the termios settings are different between raw and cbreak, see the function
> _cursesi_gettmode in tty.c which defines the mode.
The SUS Curses Issue 7 talks about cbreak(), raw(), nl() as functions affecting
input only (no mention about output). Yet tty.c, raw(), disables `OPOST` that
influences output and cbreak() leaves what ever the termios oflag has set by stty.
https://pubs.opengroup.org/onlinepubs/7908799/xcurses/cbreak.html
https://pubs.opengroup.org/onlinepubs/7908799/xcurses/nonl.html
When I was with MKS maintaining their Curses and balloting Xopen at the time, I
found historical Curses behaviour (which touches input/output terminal
behaviour) to conflict with XOpen drafts at the time which overlook how those
functions also affect terminal output.
> Also, a couple of things:
>
> 1) This isn't really a bug per se, it probably would have been better to ask on one of the
> mailing lists.
Well I filed this not as a bug, but as a `support` question, which I assume this
fell under in case it elevated to a bug.
--
Anthony C Howe
achowe@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/
From: Brett Lymn <blymn@internode.on.net>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
achowe@snert.com
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Fri, 26 Jan 2024 08:28:09 +1030
On Wed, Jan 24, 2024 at 02:55:02PM +0000, Anthony Howe wrote:
>
> The SUS Curses Issue 7 talks about cbreak(), raw(), nl() as functions affecting
> input only (no mention about output). Yet tty.c, raw(), disables `OPOST` that
> influences output and cbreak() leaves what ever the termios oflag has set by stty.
>
I am not entirely sure and susv2 is not really clear on what the effect the calls have on
output processing. My guess is OPOST is cleared in raw() to prevent special character
processing affecting the screen contents. I expect that this behaviour has been there for a
very long time so we would need to look very carefully at changing it. Having said that,
the bug that RVP pointed to dated back to the original import.
If you are adventurous you can modify tty.c to remove the output flags for raw mode and test
it.
> When I was with MKS maintaining their Curses and balloting Xopen at the time, I
> found historical Curses behaviour (which touches input/output terminal
> behaviour) to conflict with XOpen drafts at the time which overlook how those
> functions also affect terminal output.
>
Yes, and there still isn't any clarity there.
>
> Well I filed this not as a bug, but as a `support` question, which I assume this
> fell under in case it elevated to a bug.
>
Yes, I figured that you are used to dealing with commercial software support and followed
the usual process. With NetBSD support questions are handled via the mailing list, you get
a broader audience so may get more help. If it does sound like a bug then you will be asked
to log a PR. If something is definitely a bug then, please, log a PR but for things that
are not clear then try the mailing list first, it not only helps you but other people with
the same question can see the answer and benefit from it.
--
Brett Lymn
--
Sent from my NetBSD device.
"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"
From: Anthony Howe <achowe@snert.com>
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Thu, 25 Jan 2024 18:07:12 -0500
On 2024-01-25 17:00, Brett Lymn wrote:
> > The SUS Curses Issue 7 talks about cbreak(), raw(), nl() as functions affecting
> > input only (no mention about output). Yet tty.c, raw(), disables `OPOST` that
> > influences output and cbreak() leaves what ever the termios oflag has set by stty.
> >
>
> I am not entirely sure and susv2 is not really clear on what the effect the calls have on
> output processing. My guess is OPOST is cleared in raw() to prevent special character
> processing affecting the screen contents. I expect that this behaviour has been there for a
> very long time so we would need to look very carefully at changing it. Having said that,
> the bug that RVP pointed to dated back to the original import.
>
> If you are adventurous you can modify tty.c to remove the output flags for raw mode and test
> it.
I went down that road long ago at MKS with their Curses library; it was messy.
I'd have better luck getting SUS Curses to correctly document historical
behaviour than play with OPOST and all the issues that raises and possibly
breaking existing programs.
Oddly enough I took some time yesterday to play with my regression test and
created a textual TERM definition.
textterm|Minimalist Textual Test,
am, xon,
cols#80, lines#24,
bel=<BEL>\r\n,
cr=<CR>,
nel=<NL>\r\n,
ind=<IND>\r\n,
clear=<CLEAR>\r\n,
ed=<ED>\r\n,
el=<EL>\r\n,
cub1=<CUB1>\r\n,
cud1=<CUD1>\r\n,
cup=<%i%p1%d;%p2%d>\r\n,
home=<HOME>\r\n,
rmso=<RMSO>\r\n,
smso=<SMSO>,
Then twiddle the program code between cbreak() and raw(). The tests pass in in
both versions. In email with Valery Ushakov, I speculated that:
> I think there are some under the hood algorithm choices about when a CR is a
> CR and LF is a LF and when they can be used with or without OPOST set. When
> you redefine `cr`, `nel`, `cud1`, and `ind` to be longer strings it appears
> to force a consistent output choice.
Essentially I think that when certain capabilities are defined as \r, \n, and
\b, the output varies because of OPOST on/off. Set them to something different
(longer), then a particular code path is consistently used for cbreak() and raw().
Anyway. By the sounds of it there is no bug per-se, just confusion and
ambiguity with respect to SUS and historical behaviour.
Might was well close this as `WON'T FIX`. I have a work around with the above
`TERM=textterm`, I'll live with that.
Thank you for your time and attention,
--
Anthony C Howe
achowe@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: uwe@netbsd.org, blymn@netbsd.org, dickey@invisible-island.net
Subject: Re: lib/57867: Why does cbreak or raw affect terminal output
differently?
Date: Fri, 26 Jan 2024 00:43:15 +0000 (UTC)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1428639238-1706229795=:27462
Content-Type: text/plain; format=flowed; charset=UTF-8
Content-Transfer-Encoding: 8BIT
On Wed, 24 Jan 2024, Valery Ushakov wrote:
> It was not clear from the original question if input was involved,
> presumably yes, so there may be differences.
>
> I can't quite remember all the nuances, so when I need to, I check
> this table from SCO UNIX Development System, User Interface Guide:
>
> [...]
>
Thanks for that table, but, that too, is only concerned with input behaviour.
I emailed Tom Dickey to find out how ncurses handled this, and I reproduce
his answers below:
---START E-MAIL 1---
> Does ncurses produce different _output_ depending on whether cbreak() or raw()
> has been called?
no - it only affects input processing - but that includes whether control
characters are echoed or not. I don't believe that's what you are asking
about, though.
> This question was asked in NetBSD PR #57867:
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57867
> The answer, for BSD curses, seems to be yes, but, I can't see precisely what
> or why.
ncurses doesn't change OPOST, while NetBSD turns it off in raw but not
cbreak (as well as turning on ONLCR - but ncurses turns that off in initscr).
NetBSD's nl/nonl use a detail which ncurses doesn't do anymore:
20201003
+ remove output-related checks for nl/nonl (report by Leon Winter).
The bug report has a different story from what I found while researching
this. Here's what I decided to document:
From the outset, ncurses used nl/nonl to control the conversion of new‐
lines to carriage return/line-feed on output as well as input. XSI
Curses documents only the use of these functions for input. This dif‐
ference arose from converting the pcurses source (which used ioctl
calls with the sgttyb structure) to termios (i.e., the POSIX terminal
interface). In the former, both input and output were controlled via a
single option CRMOD, while the latter separates these features. Be‐
cause that conversion interferes with output optimization, nl/nonl were
amended after ncurses 6.2 to eliminate their effect on output.
---END E-MAIL 1---
---START E-MAIL 2---
> Cool! I suppose this is going to go into the new ncurses.3x coming this
> weekend?
It's been there a couple of years (I quoted the NEWS item from 2020).
Whenever Branden gets tired of bombarding me with formatting changes,
I've a few things to finish off for ncurses 6.5
> Can I quote your answer when I reply to the PR? I'll CC: you, of course.
sure - my point in the manpage was that the original BSD curses tied the
input/output together because of the underlying calls, but that X/Open
Curses didn't need or actually want that.
Actually, Solaris kept the feature: in its xcurses, it sets OPOST and ONLCR
with nl(), and clears them with nonl(). But the more commonly used SVR4
curses just clears both in newscreen.c:
/* set tty settings to something reasonable for us */
#ifdef SYSV
PROGTTYS.c_lflag &= ~ECHO;
PROGTTYS.c_lflag |= ISIG;
PROGTTYS.c_oflag &= ~(OCRNL|ONLCR); /* why would anyone set OCRNL? */
#else /* SYSV */
PROGTTY.sg_flags &= ~(RAW|ECHO|CRMOD);
#endif /* SYSV */
iirc, Solaris xcurses comments indicate that it was developed by MKS,
and has several differences from SVr4 curses. The source code is viewable
on illumos-gate, though of course there's no history before 2005, and only
comments here and there to help.
So... after investigating this a few years ago, I agreed with Leon
that it shouldn't affect output processing, and documented it.
---END E-MAIL 2---
-RVP
--0-1428639238-1706229795=:27462--
State-Changed-From-To: open->closed
State-Changed-By: blymn@NetBSD.org
State-Changed-When: Fri, 23 Feb 2024 06:03:56 +0000
State-Changed-Why:
This is not a bug just a behaviour of our curses. After discussion
with the submitter he has said this can be closed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home