Please show the scenario where bash isn't preserving the ECHOCTL flag if it's present. The function you're modifying below changes the settings in a termios struct that holds the current terminal settings. If the ECHOCTL flag is set there, bash won't change it.Further, the function you're modifying -- tt_setonechar -- is only used by the read builtin to support `read -n' while the shell's input is a tty.Please review the bug report (Bug 284513 on FreeBSD) for full context. I'm not referring to running bash in its default (interactive) mode but specifically to running bash as sh via its symlink—in other words, when bash is invoked as "sh" (sh‑mode).
The bug report refers to a version of bash built with a minimal configuration, so we can remove readline from the equation. It's just going to be minimal-bash-invoked-as-sh using whatever the tty interface gives it.
In this mode, the terminal behavior should mimic that of the traditional bourne shell, and the user’s explicit configuration of the echoctl flag (e.g., via stty -echoctl) should be preserved.
It is. I don't run FreeBSD, and I certainly don't run a serial terminal
configuration. Let's see what happens when I try this on my system:
local(1)$ PS1='$ ' ./sh --norc
$ echo $BASH_VERSION
5.2.37(1)-release
$ stty -a
speed 9600 baud; 30 rows; 80 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
$ stty -echoctl
$ ls
$ sleep 5
$ stty echoctl
$ ls^C
$ sleep 5
^C
$ exit
exit
There are two cases to consider: one when bash is reading a command, and
one when another process has the tty. You can see that the kernel echoes
^C when echoctl is set and does not when it isn't.
I hit ^C in the same place in both scenarios.
The issue is reproducible when using a serial terminal configuration. In our tests, even though the termios struct initially has the ECHOCTL flag set (or cleared as the user desires), bash in sh‑mode ends up reinitializing the terminal attributes in a way that overwrites that setting. Yes, tt_setonechar() is used by the read builtin to support `read -n` when input is from a tty, but note that this is the code path used in sh‑mode.
It is not. There is no call to any of the tty functions to set character- at-a-time behavior using those functions (there are several) anywhere in the source except in the read builtin. There might be something going on, but that's not it. Maybe you have something in a startup file that runs read -n, but there's no evidence of that.
Our patch shows that preserving the echoctl flag in tt_setonechar() prevents the unexpected behavior (i.e., the disappearance of "^C" when CTRL‑C is pressed).
It doesn't. The link you provided shows that Dennis built bash with a
minimal config and it works correctly (the `debug2' user and the
`/usr/local/shell/bash' login shell). Are you telling me that this shell,
when run as `sh', behaves differently? Why not show that?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
