i suggest u be some kinder .. On Mon, Feb 3, 2025, 11:43 PM Zeffie via Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org> wrote:
> 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 > >
