I’m going to downvote your comment based on that first quote reply, because I think that’s an extreme take that’s unwarranted. You’ve essentially dissed people who use it for CI/CD and suggested that their pipeline is not robust because of their choice of using Bash at all.

And judging by your second comment, I can see that you have very strong opinions against bash for reasons that I don’t find convincing, other than what seems to me like irrational hatred from being rather uninformed. It’s fine being uninformed, but I suggest you tame your opinions and expectations with that.

About shared libraries, many popular languages, Python being a pretty good example, do rely on these to get performance that would be really hard to get from their own interpreters / compilers, or if re-implementing it in the language would be pretty pointless given the existence of a shared library, which would be much better scrutinized, is audited, and is battle-tested. libcrypto is one example. Pandas depends on NumPy, which depends on, I believe, libblas and liblapack, both written in C, and I think one if not both of these offer a cli to get answers as well. libssh is depended upon by many programming languages with an ssh library (though there are also people who choose to implement their own libssh in their language of choice). Any vulnerabilities found in these shared libraries would affect all libraries that depend on them, regardless of the programming language you use.

If production only implies systems in a user’s path and not anything else about production data, then sure, my example is not production. That said though, I wouldn’t use bash for anything that’s in a user’s path. Those need to stay around, possible change frequently, and not go down. Bash is not your language for that and that’s fine. You’re attacking a strawman that you’ve constructed here though.

If your temporary small script morphs into a monster and you’re still using bash, bash isn’t at fault. You and your team are. You’ve all failed to anticipate that change and misunderstood the “temporary” nature of your script, and allowed your “temporary thing” to become permanent. That’s a management issue, not a language choice. You’ve moved that goalpost and failed to change your strategy to hit that goal.

You could use Deno, but then my point stands. You have to write a function to handle the case where an env var isn’t provided, that’s boilerplate. You have to get a library for, say, accessing contents in Azure or AWS, set that up, figure out how that api works, etc, while you could already do that with the awscli and probably already did it to check if you could get what you want. What’s the syntax for mkdir? What’s it for mkdir -p? What about other options? If you already use the terminal frequently, some of these are your basic bread and butter and you know them probably by heart. Unless you start doing that with Deno, you won’t reach the level of familiarity you can get with the shell (whichever shell you use ofc).

And many argue against bash with regards to error handling. You don’t always need something that proper language has. You don’t always need to handle every possible error state differently, assuming you have multiple. Did it fail? Can you tolerate that failure? Yup? Good. No? Can you do something else to get what you want or make it tolerable? Yes? Good. No? Maybe you don’t want to use bash then.