On Mon, Feb 3, 2025, at 5:43 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell 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.
This is uncalled-for and unwelcome.
> 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`
As Greg already noted, this is incorrect.
% ln -s ~/build/bash-5.3-testing/bash /tmp/sh
% unset -v BASH_VERSION
% /tmp/sh --norc -c 'echo $BASH_VERSION'
5.3.0(1)-beta
And it has been for a long time.
% /bin/sh --version | head -n 1
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
% unset -v BASH_VERSION
% /bin/sh --norc -c 'echo $BASH_VERSION'
3.2.57(1)-release
> 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.
Are we reading the same bug report? Isn't 284513 about FreeBSD's
default /bin/sh, which is not bash, but an Almquist shell?
https://www.in-ulm.de/~mascheck/various/ash/#freebsd
https://cgit.freebsd.org/src/tree/bin/sh/main.c?h=release/14.2.0-p1#n7
Are you claiming the same thing happens with bash invoked as "sh"?
> 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.
Chet explicitly launched the testing shell as "sh". Does this not
qualify as "sh-mode" to you?
> 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 does not claim that "the issue only occurs in a
serial terminal configuration". The bug reporter said:
Why the serial terminal config? Simply to remove any
possible network layer from the problem. There is no telnet
here. No SSHd daemon.
As I'll describe momentarily, I can reproduce the bug described in
the bug report without using a serial connection. But that bug is
not the one that you're asserting exists in bash.
> The bug report explicitly states:
>
> "The issue is reproducible when using a serial terminal
> configuration."
Where does this text appear in the bug report?
> 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.
Where is "tt_setonechar" mentioned in the bug report?
> 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 bug report does not claim that bash-in-sh-mode improperly resets
termios flags under certain conditions. It claims that FreeBSD's
Almquist shell does.
> 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.
For the record, I'm not opining on whether bash really does have a
problem, or whether this patch fixes it.
> 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.
That is not what the bug report documents. The bug report documents
an issue in FreeBSD's Almquist shell.
> 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).
The bug report was not submitted against a FreeBSD build of Bash.
It was submitted against FreeBSD's Almquist shell.
> 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.
For the lulz, I took some time to give this a shot in VMware Fusion,
but not enough time to figure out how to set up a serial connection.
The bug reporter said that he used a serial terminal "[s]imply to
remove any possible network layer from the problem", so I worked
in the console (i.e., typing directly into Fusion) to achieve the
same thing.
Unfortunately, I couldn't compile bash using the configuration
described in the bug report; I kept getting build errors, which I'm
not going to debug right now. I used bash 5.2.37 from pkg instead.
Under these conditions, I can verify that:
- /bin/sh is not bash. Sven Mascheck's whatshell.sh [*] identifies
it as "ash (FreeBSD 11.0 ff)".
- /bin/sh does exhibit the problem described in the bug report.
- bash from pkg, when executed via a symbolic link at /tmp/sh, does
not exhibit the problem described in the bug report. It behaves
identically to the bug reporter's custom-configured bash -- that
is, it behaves correctly.
- bash from pkg, when executed via a symbolic link at /tmp/sh, does
not modify echoctl at startup. stty -a reports the same value
of "echoctl" or "-echoctl" outside of /tmp/sh and inside of it.
[*] https://www.in-ulm.de/~mascheck/various/whatshell/
> 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.
I'm sorry you didn't get the response you expected, and you're
free to express your disagreements, but as a guest here you've
been incredibly rude.
--
vq
