A Second Search for Bash Scripting Alternatives

I hate bash, but it's always the first thing I start scripting in when I need to glue some things together. I tend to go in the following order as complexity and a need for robustness increases.

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.

Perl excels at most of their list, though I understand why they aren't considering it. Just funny that you look at the list and one language in particular pops to mind.

In defense of bash, in spite of its many footguns... you do yourself a disservice if you refuse to learn bash, which is rock-solid stable and has basically ubiquitous deployment. SSH into any server or use any UNIX-like environment and you are instantly at home. While JS and Ruby ecosystems churn every year and mandate yet another round of dependency hell and keeping up with the latest and greatest in rubocop bikeshedding, bash just keeps on ticking throughout the years with little to no recurring maintenance burden.

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.

Whenever people look for "better shell scripting", they always run into the second-system effect. Trying to shove everything that wasn't in the first system, into the second system.

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.

Unpopular opinion but powershell, available on Linux, supports all of the things this article wanted to do out the box.

I'm fluent in bash but I have to say it is the jankiest, messiest language I've ever used. I can't believe another default hasn't totally obliterated it into obsolescence. Maybe because it is so ubiquitous people are afraid of all the work required to move. Wait, that's me.

Been using nushell for the past couple years as my main shell environment and for any random scripts I need to use. It's everything I want out of a shell scripting language. It has even replaced "upgrading" to python in a lot of instances.

Its strange people of every generation, almost everyday keeps discovering the need for Perl.

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.

Using JavaScript via zx is nice.

No xonsh? (https://xon.sh/) Seems to hit most of the requirements.

Been happily using it since 2018. It's great not to have to learn a whole other language just to do scripting.

ABS creator here. Thanks for the kind words :)

Long way to go but was very happy to see someone wanting a better alternative to bash and trying ABS out!

The answer is PowerShell. Works great in Linux.

ChatGPT is quite good at bash and improves the learning curve/time to market by a lot

> bash: 3/5 stars (no one really knows bash)

LOL, so true

#!/usr/bin/env cargo

Im exicted about cargo-script (rust). hopefully soon.

https://rust-lang.github.io/rfcs/3424-cargo-script.html