Thank you for taking the time to not review the FreeBSD bug report (Bug
284513) in full before responding. Your willingness to speculate on
behaviors without testing in the relevant environment is duly noted and
much appreciated.
Now, let’s break down the issues with your response:
1. `echo $BASH_VERSION` is Irrelevant
You seem to have completely misunderstood the context of the bug report.
The command:
```sh
echo $BASH_VERSION
```
is entirely irrelevant in this discussion because:
`BASH_VERSION` is only set when Bash is running as Bash.
When Bash is invoked as `sh` (i.e., in sh-mode via symlink), it does not
necessarily set `BASH_VERSION` and behaves differently from its normal
interactive mode.
The issue being reported occurs specifically in sh-mode, which means
that confirming `BASH_VERSION` only proves that you’re not testing the
relevant scenario.
Your test confirms that you are running Bash in normal mode, not in
sh-mode. That is the opposite of what is required to reproduce the
issue.
2. Acknowledging That This Is a TTY Issue—Then Ignoring It
You admit:
"I don't run FreeBSD, and I certainly don't run a serial terminal
configuration."
Yet, you then proceed to run tests without a serial terminal setup—the
very condition under which the bug manifests. If the issue only occurs
in a serial terminal configuration, why would you expect to see it
without one? That’s like troubleshooting a car’s braking system by
testing the air conditioning.
The bug report explicitly states:
"The issue is reproducible when using a serial terminal
configuration."
By failing to test under the relevant conditions, your results are
meaningless. You cannot disprove a bug by running an irrelevant test.
3. `tt_setonechar()` Is Used in sh-Mode
You claim:
"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."
This is incorrect. The bug report explicitly documents that in sh-mode,
`tt_setonechar()` is involved in terminal attribute reinitialization in
a way that overwrites the user's explicitly set echoctl flag. Your
assertion that it is only used by `read -n` in standard Bash mode
ignores the fact that sh-mode has different handling, and in this case,
it is modifying termios settings when it should not.
If your argument is that this behavior doesn’t exist, then please
provide an actual source-level explanation of why the reported behavior
does occur when Bash is invoked as `sh`. Otherwise, your statement is an
assumption, not a refutation.
4. Your Own `stty` Tests Contradict Your Conclusion
In your test:
```sh
$ stty -echoctl
$ ls
$ sleep 5
$ stty echoctl
$ ls^C
$ sleep 5
^C
```
All you’ve done here is show that Bash correctly respects `stty
-echoctl` in interactive mode when running as Bash. This does not
address the bug report’s claim that Bash-in-sh-mode improperly resets
termios flags in certain conditions.
The fact that you manually toggled `stty echoctl` proves nothing about
whether Bash (when invoked as `sh`) is overriding the setting at
startup, which is the actual issue under discussion.
5. The Patch Demonstrates the Fix—You Just Ignored It
You stated:
"It doesn't. The link you provided shows that Dennis built bash with
a minimal config and it works correctly."
Except that the patch explicitly shows that preserving ECHOCTL in
`tt_setonechar()` prevents the unwanted behavior. If it was not
necessary, why does the patch solve the problem? You haven’t engaged
with that at all.
The proper way to challenge the patch would be to:
Explain why the patch appears to work yet is unnecessary.
Show the precise conditions under which Bash-in-sh-mode is NOT modifying
termios inappropriately.
Demonstrate how an alternative explanation accounts for the observed
behavior.
Instead, you dismissed it outright without addressing the actual fix.
6. "Why Not Show That?"
Your final question:
"Are you telling me that this shell, when run as `sh`, behaves
differently? Why not show that?"
We DID show that. That’s literally what the bug report documents. What
we didn’t do was run an irrelevant test in the wrong environment and
then act as though that somehow disproves the issue.
If you’re actually interested in verifying this issue properly:
1. Use FreeBSD (since the bug report was submitted against a FreeBSD
build of Bash).
2. Invoke Bash via the `sh` symlink to ensure it runs in sh-mode.
3. Use a serial terminal setup to match the conditions under which the
bug manifests.
4. Explicitly check the termios state before and after Bash-in-sh-mode
starts to see whether it modifies `ECHOCTL` unexpectedly.
Until you do this, your results are irrelevant to the discussion.
Final Thoughts
Thank you once again for responding without actually addressing the bug
report's core claims. Your contribution to testing an entirely different
scenario and concluding that the bug does not exist has been very
enlightening.
If you would like to engage with the issue seriously, please conduct
tests under the correct conditions rather than dismissing reports based
on unrelated experiments.
Zeffie
