On Mon, Jul 8, 2024 at 11:16 AM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote: > The only things that the shell has going for it is that it's widely deployed > and stable over the long term. > Otherwise it's a terrible language, and any sane programmer should avoid it > entirely: > This has already been happening, and Bash is >this< close to become an > irrelevant historical footnote. > If you modify Bash in ways that are not backwards compatible, you're then > writing in a new language that no new project is likely to adopt.
These are just your opinions. > That's what "worth breaking existing code" costs in reality: other people's > stuff breaks when they've had zero advance notice, because they aren't the > people deciding to upgrade Bash. This I agree with, but personally I don't think the change we discuss here is that big. > PPS: In my opinion, the only hope for Bash to continue to exist in the long > term is for it to either: > (a) absolutely guarantee stability, forsaking all new features; or > (b) adopt a full suite of features that make it into a "normal" programming > language, including: support for modules written for different versions of > Bash to safely cohabitate in a single script; lexical scoping with > namespaces; being able to store references in variables, including some kinds > of handles for filedescriptors, functions, processes, and process groups; > some mechanism to perform rewriting during parsing (going well beyond what > aliases can do) so that new features can be proposed and implemented in shell > before being implemented in the C core. And all of that while not breaking > code that doesn't ask for these new features. You're wasting your breath.
