On 12/11/23 7:23 PM, Martin D Kealey wrote:
On Mon, 11 Dec 2023 at 06:55, Chet Ramey <chet.ra...@case.edu <mailto:chet.ra...@case.edu>> wrote:It came up as a bug report in https://lists.gnu.org/archive/html/bug-bash/2019-06/mstheng00042.html <https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00042.html> (part of the followup discussion after the second linked thread above) and the consensus among those who participated was that it was a good thing to prevent base# without any digits from silently being treated as 0. The wrap-up at the end of that discussion was this: /I'm not sure how relevant that language is to integer constants in expressions. I could also note that the language describing the base#n syntax only talks about digits, letters, `@', and `_'. The bash definition of arithmetic evaluation is taken from C. That includes integer constants, and, while the base#value syntax clearly extends the C definition of a constant, the `-' (and `+', FWIW) is still an operator as defined by C./One could be forgiven for taking that to mean "this is behaving as expected and won't be changed".
In the sense that you can't have an operator (`-') in the middle of an integer constant. That wasn't going to change. The issue then became how to prevent the same thing from happening to other users, and whether silently treating no digits following the `#' as 0 was actually helpful, since it ran counter to the documentation.
Do you think there would have been more discussion in different circumstances?That entire discussion was between 4 people, and started and finished in less than a week.Anyone who happened not to be around would have missed it, including me.Can a consensus among 4 people really be fair and representative of millions of Bash users?
Participation has always been based on the number of interested participants. The discussion about a particular bug report is no different.
Would you have participated, considering there's no sign of you on the
bug-bash list between 2016 and 2020?
When the instructions say "send bug reports to X-bugs", it's natural to
assume that the primary audience for X-bugs is the people who fix bugs, and
other people should stay away. So for a long time I didn't join this list
because I wasn't in a position to contribute as a fixer.
"The discussion list `bug-bash@gnu.org' often contains information about new ports of Bash, or discussions of new features or behavior changes that people would like." That's from the README. "Suggestions and `philosophical' bug reports may be mailed to bug-bash@gnu.org or posted to the Usenet newsgroup gnu.bash.bug." That's from the man page. The info document has the same language. The web page on gnu.org says"<bug-bash@gnu.org> (web interface) is used to report bugs or discuss most aspects of developing Bash."
These imply that bug-bash isn't restricted to bug reports.
Of course, that's not the only reason why people don't participate: sometimes real life gets in the way and we don't have time to participate, sometimes for weeks on end.
Sure, everyone has competing interests.
But yes, I would have participated had I known this discussion was going on.
Maybe. None of us can go back. All you can do is move forward.
In most projects this lack of discussion wouldn't matter: after the discussion comes a proposed code change, and then code review, and then even after release, it's an "experimental feature that may be retracted".
Features appear in the devel branch for months before they get included in a formal release. There is ample opportunity to read the change logs, look at the referenced discussions (nearly all changes are annotated with the name of the person who suggested or reported them), look at the code, and have a discussion. There are a number of people on here who report bugs and ask questions about the devel branch. It does require effort.
When we don't have those extra steps, and every release of bash is "forever", yes, we need more considered discussion up front.
Those extra steps are the product of effort, see above. If you want to change the distro policy of shipping and "supporting" oldversions (Apple is by far the most egregious offender here), or not moving to new versions in a timely-enough fashion, or only looking at changes
when I put out a release candidate, then it seems like you'd need to talk to the distros or vendors. I support only the current release. I talked about that in https://lists.gnu.org/archive/html/bug-bash/2023-12/msg00055.html But one of the wonderful things about free software is that it's right there for you -- it doesn't disappear when a new release comes out. You don't lose anything. That's "forever." Chet -- ``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
