Bash 5.2 released

Posted Sep 28, 2022 2:53 UTC (Wed) by kilobyte (subscriber, #108024)
In reply to: Bash 5.2 released by binkley
Parent article: Bash 5.2 released

BASH is fit for an interactive shell, and that's it's design aim. For shell scripting there's dash and other POSIX-compliant shells that do implement that stable platform you're asking for. And if that's not enough, you're far better off using a proper scripting language such as Perl.

Bash 5.2 released

Posted Sep 28, 2022 7:39 UTC (Wed) by eru (subscriber, #2753) [Link]

That is not my impression. All these programming features (like arrays) are really useful only in scripts, almost never interactively. if they really aimed to help interactivity, they would concentrate on command line editing, automatic expansion of commands and options, online helps etc.

Bash 5.2 released

Posted Sep 28, 2022 7:52 UTC (Wed) by maxfragg (guest, #122266) [Link] (6 responses)

The point is, most people don't need true POSIX compatibility, since their scripts will never run outside a modern linux anyways and writing true POSIX scripts is really unnecessarily painful for anything not trivial, as I can tell after doing this for 5 years now.

Bash 5.2 released

Posted Sep 28, 2022 20:48 UTC (Wed) by k8to (guest, #15413) [Link] (3 responses)

Yeah, I I have to agree. I've deployed a lot of minimum Bourne compatability scripts to run across 6 or 7 Unix variants, and it was a lot less painful to do system instrumentation fact gathering in shell than it would have been in c, it was still a lot of sunk time to properly validate them, even with a decade of accumulated knowledge. And even there I couldn't really rely on every aspect of a posix environment being available.

Everything I've done since, just putting bin/bash at the script start was fine. They were only ever going to run on Linux in cloud land, and usually the startup overhead of bash was overshadowed by being able to kill off lots of forks.

That said, I generally prefer the pain of automating in python so that failures are explicitly caught and fixed by default. Shell for me is more of a tool for doing immediate work. Testing some park of things, doing something 100 times while sniffing for failures that probably makes no sense to put on a test, etc, ie scripts you throw away. And for that, bash and zsh type things still feel good.

Bash 5.2 released

Posted Sep 29, 2022 4:17 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (2 responses)

I sometimes find shells useful in contexts where the silly thing really does need to run as a subprocess, and then I really do need to parse its stdout, rather than having a nice sensible library binding that I can just call into. Yes, I know Python has subprocess etc. and other languages have the same, but shell pipelines are just so much more expressive and concise for that sort of thing...

Bash 5.2 released

Posted Sep 29, 2022 19:26 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (1 responses)

Plus shell scripts can be fixed / adapted by anyone.

Bash 5.2 released

Posted Sep 30, 2022 13:13 UTC (Fri) by Wol (subscriber, #4433) [Link]

> Plus shell scripts can be fixed / adapted by anyone.

You may be a bash wizard, but please don't speak for the rest of us :-)

Cheers,
Wol

Bash 5.2 released

Posted Sep 29, 2022 9:59 UTC (Thu) by scientes (guest, #83068) [Link] (1 responses)

I also don't see why. While pipes are pretty cool, the way the SH language is implemented on top of the 386 is friggen awful, as something like `[ ]` (test) will use like 100+KB of written environment on stack and a new processs and all sorts of other garbage.

Why not just use luajit or something?

Bash 5.2 released

Posted Sep 30, 2022 11:15 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> Why not just use luajit or something?

Well, oilshell[1] already exists for those looking for non-POSIX shell experiences. Or p9's rc if you're more into that kind of thing.

[1]https://www.oilshell.org/