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). 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.
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. 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).
In summary, the problem isn’t about bash in its normal interactive
mode—it’s about bash when running as sh (via its link), where the
terminal initialization must respect the user's echoctl setting. The bug
report details how, under serial terminal conditions, the behavior is
not as expected, and the patch fixes that.
Zeffie
