A Second Search for Bash Scripting Alternatives
monzool.net
monzool.net
1. Bash (or ysh, which I do prefer but isn't as available)
2. Python, using the `sh` package as needed. It's been great for upgrading shell scripts, and `sh` is really nice to use.
3. Rust, usually. That's my personal language of choice for "real" projects.
I have a number of projects at each stage actually, though most of the things I'd call a real "project" with it's own repo end up as Rust projects.
That being said, if you are doing something other than just piping together processes and managing unstructured streams of flat plaintext, bash is the wrong tool for the job. bash is best used interactively, in the REPL, for having a back-and-forth conversation with the machine and interrogating its current state (filesystem, resource usage...), or that of other machines over the network (that is, using dig, curl, openssl, ping, mtr, etc), and processing streams of text. Even for lightly structured data, like if I am doing boring, garbage CRUDdy tedium on the web and need to figure out how to do some rudimentary transform of a JSON document, figure out which headers to send and which endpoints to hit, curl and jq it is - and there I am, reshaping the data in as interactive of an environment it gets.
The minute I need to write something for a non-interactive, end-user use case, with requirements for better domain modelling / structuring of data, testing, deployment, readability, maintainability, extensibility, etc. it is time to reach for a more modern language. But if you want to talk to the machine, virtually any (non-Windows) machine, interactively, bash is your lingua franca, or perhaps your Latin/Ancient Greek/Aramaic, esoteric and outdated as it is.
I also get the feeling that people just recoil at any level of complexity and need to hide behind their clean, simple abstractions these days. As a Haskell enthusiast, I am also susceptible to this tendency, but one needs to be at least capable of diving into the historical, messy work underneath the hood.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
There is a bunch of bash that you should not learn. The differing coprocess syntax from korn is one particular bugbear. Still, if you are hacking on ReaR or other critical tools that sink deep into bash's slang, you don't have much choice.
The Debian/Ubuntu family uses the "Debian Almquist Shell" (dash) as the system shell (#!/bin/sh) for a number of reasons. It is very much not compatible with anything fancy from bash (or korn). The bash shell is available as #!/bin/bash, but that opens the door to a new set of problems (in that POSIX mode is not enabled).
In the embedded realm, busybox also implements the Almquist shell, but it does throw simple bash "slang" back in (but not this does not include arrays).
OpenWRT is undoubtedly using busybox. I actually saw the busybox copyright on a point-of-sale terminal at Old Navy a few years ago. The embedded realm is vast, and bash is too big for it, or intolerable because of gplv3.
Android uses mksh as the system shell. The more that you know of the korn dialects, the more comfortable you will be in scripting on Android. There is no native bash, as Android's userland is BSD. That realm is also vast.
Finally, Debian/Ubuntu does give you /bin/bash, but if you don't understand the need for "set -o posix" then the scripts that you wrote for CentOS will fail in many interesting ways, because you are carrying the baggage of bash's first decade, before the POSIX shell standard.
So yes, cutting your scripting away to pure POSIX.2 has considerable worth. It runs everywhere.
Bash shell scripting is already close to perfect for what it is intended. Where people always complain is one of three areas: 1) "footguns", 2) "not enough features", 3) "not a programming language", 4) inexperience.
1) is almost entirely due to it being a programming-like language bolted onto an interactive console terminal. Bash has a lot of changes over vanilla Bourne/Posix that make it less console-y and more programming-y. But if you take away the interactive-terminal-ness itself, then you don't need most of the Bashisms.
2) is almost always a mistake. Bash has pretty much all the features you need. But again, it's hampered by the interactive-terminal-ness; take that away, and you can do pretty much anything, with ease.
3) is because programmers don't understand what scripts are for. They are not for writing robust programs. They are for solving a small problem, in a specific, tailored way, with the least amount of effort and time. This means that you should be abandoning all of the programmer's best practices and rules. Throw out safety, reliability, consistency, verifiability, etc. What you end up with is a solution that works, with nothing extra.
4) comes when people simply don't know how to use Bash very well, which is 90% of the time. Ever since I became a programmer two decades ago, the great unwashed masses of techno-dweebs who call themselves "programmers" have been picking up complex and nuanced technology that they have never bother to formally learn, and then complain that it sucks and they need an alternative. When in reality, the problem is almost always either a) they didn't read the manual, b) they haven't practiced using it, or c) they're using the wrong tool anyway.
Doesn't matter if you disagree with me. We will be using the same shell scripts in 20 years. Know why? Because you can't make it any simpler, and it just works. Complain all you want about it not being perfect. You simply will not be able to make something better without simultaneously making it worse. Its killer feature is its lack of features and design. It is the anti-programming language. And boy do I love it.
This kind of Dunning-Kruger-esque arrogance in software is intensely aggravating to me. Nobody presumes that you can master, say, a musical instrument, without intensive practice over a timespan of years; yet for some reason people can get plopped out the other end of a bootcamp and suddenly identify as world class programmers in 16 weeks without the requisite thousands of hours of practice with hands on keyboard, reading the manual, studying how the computer works, and actually solving technical problems.
I get new grads with great grades, who are decent junior devs that are productive in, say, Java and one or maybe two related things like SpringBoot or Hikari, but don't even know about simple/common things that sometimes baffle me.
They seem to think I'm some sort of wizard because I can quickly put together simple commands line pipelines using things like grep, awk, sed, sort, uniq, wc - and dig useful answers or insights out of log files or csv files or database exports, or even JSON by using jq as well.
It amazes me that some of them have never even heard of the existence of tools like that, or how easily you can pipe the output from one to the input of another and chain them up in such useful ways.
(At the same time, I'm fairly sure I have similar black holes in my knowledge and mental map of how things that other people specialise in work. :shrug: )
I'm not a recent grad by any means. I have heard of those tools and even used them on occasion. The problem is "on occasion". There's no way I want to keep relearning awk every time it might be useful.
These days, though, LLMs are a saving grace. It's rare that I ask it to provide me with a command line to solve a problem and it gets it wrong. I still have the burden of verifying, but it's a happy medium between your expertise and my writing everything in Python.
And I don't really care. I'm super comfortable with one-liners in my bash shell. I can do useful stuff in bash scripts, but typically with a base script gets to more than a dozen or so lines, I find myself way more productive rewriting it in Python instead. Not because Python is "better" or because bash is "worse", but because _I'm_ better with Python and _I'm_ worse with bash. And I don't feel any urgent need to get better at bash, because the work I do means I pretty much always have Python available (at least everywhere I have bash available).
I know bash is way more capable than my kindergarten-grade use of it. And it'll remain in my toolkit and crontab for as long as unix-like OSen exist. But I'll be very unlikely to ever keep writing a bash script past a dozen or two lines ever again.
It is very difficult to write a parser for any derivative of the POSIX shell. The lex/yacc utilities cannot be used; the lexer and parser must exchange state.
It would be better if the shell was an LR-parsed language with a yacc grammar. The yacc utility is itself in POSIX.2.
Here is a talk about an OCaml implementation of a parser for the POSIX shell:
https://archive.fosdem.org/2018/schedule/event/code_parsing_...
Here is another talk about an Ada parser implementation:
https://archive.fosdem.org/2019/schedule/event/ada_shell/
The language grammar is unfortunate.
1. fish 2. xonsh 3. nushell
I often find people making such claims simply don't know much about other shells.
Its biggest flawed design decision is word splitting by default and Bash's lack of a standard library helper functions for arrays and associative arrays. These could also be implemented as bash native extensions without build-time modification with a user-provided programmatic builtin. I could be wrong, but zsh may be able to add compiled functionality at runtime dynamically as well.
Perl was made to solve precisely these kind of problems.
Just use Perl. Its fast, matured, has CPAN and is dedicated to maintaining backwards compatibility for years to come. Using anything else will not make all that much sense. You will be reinventing a whole universe(and badly from scratch). And achieve nothing at the end.
Perl+LLM is a match made in heaven.
Been happily using it since 2018. It's great not to have to learn a whole other language just to do scripting.
Long way to go but was very happy to see someone wanting a better alternative to bash and trying ABS out!
LOL, so true
Im exicted about cargo-script (rust). hopefully soon.