Bash is widely used in production environments for scripting all over enterprises.

But it shouldn’t be.

The people you work with just don’t have much experience at lots of shops I would think.

More likely they do have experience of it and have learnt that it’s a bad idea.

I’ve never had that impression, and I know that even large enterprises have Bash scripts essentially supporting a lot of the work of a lot of their employees. But there are also many very loud voices that seems to like screaming that you shouldn’t use Bash almost at all.

You can take a look at the other comments to see how some are entirely turned off by even the idea of using bash, and there aren’t just a few of them.

Pretty much all languages are middleware, and most of the original code was shell/bash.

What? I genuinely do not know what you mean by this.

Basically a wrapper to run rust scripts right from the command line.

Isn’t that just Python? :v

How easily can you start parsing arguments and read env vars? Do people import clap and such to provide support for those sorts of needs?

Yeah, sometimes I’ll use that just to have the sane control flow of Rust, while still performing most tasks via commands.

You can throw down a function like this to reduce the boilerplate for calling commands:

fn run(command: &str) {
    let status = Command::new("sh")
        .arg("-c")
        .arg(command)
        .status()
        .unwrap();
    assert!(status.success());
}

Then you can just write run("echo 'hello world' > test.txt"); to run your command.

Serious question (as a bash complainer):

Have I missed an amazing bash library for secure database access that justifies a “perfectly good” here?

I don’t necessarily agree that all simple tasks will lead to the need for a test suite to accommodate more complex requirements. If it does reach that point,

1. Your simple bash script has and is already providing basic value.
2. You can (and should) move onto a more robust language to do more complicated things and bring in a test suite, all while you have something functional and delivering value.

I also don’t agree that you can just solder on whatever small task you have to whatever systems you already have up and running. That’s how you make a Frankenstein. Someone at some point will have to come do something about your little section because it started breaking, or causing other things to break. It could be throwing error messages because somebody changed the underlying db schema. It could be calling and retrying a network call and due to, perhaps, poorly configured backoff strategy, you’re tripping up monitoring alerts.

That said, I do agree on it suitable for temporary tasks.

Those two libraries actually look pretty good, and seems like you can remove a lot of the boilerplate-y code you’d need to write without them. I will keep those in mind.

That said, I don’t necessarily agree that bash is bad from a maintainability standpoint. In a team where it’s not commonly used, yeah, nobody will like it, but that’s just the same as nobody would like it if I wrote in some language the team doesn’t already use? For really simple, well-defined tasks that you make really clear to stakeholders that complexity is just a burden for everyone, the code should be fairly simple and straightforward. If it ever needs to get complicated, then you should, for sure, ditch bash and go for a larger language.

If you need anything that complex and that it’s critical for, say, customers, or people doing things directly for customers, you probably shouldn’t use bash. Anything that needs to grow? Definitely not bash. I’m not saying bash is what you should use if you want it to grow into, say, a web server, but that it’s good enough for small tasks that you don’t expect to grow in complexity.

I’m going to read this with a big “/s” at the end there xD

-e is great until there’s a command that you want to allow to fail in some scenario.

I know OP is talking about bash specifically but pipefail isn’t portable and I’m not always on a system with bash installed.

If you’re writing a lot of shell scripts and checking them with Shellcheck, and you’re still convinced that it’s totally safe… I tip my hat to you.

Set don’t forget set -E as well to exit on failed subshells.

You seem to be familiar with Bash syntax. But others may not be.

If by this you mean that the Bash syntax for doing certain things is horrible and that it could be expressed more clearly in something else, then yes, I agree, otherwise I’m not sure this is a problem on the same level as others.

OP could pick any language and have the same problem. Except maybe Python, but even that strays into symbolic line noise once a project gets big enough.

Either way, comments can be helpful when strange constructs are used. There are comments in my own Bash scripts that say what a line is doing rather than just why precisely because of this.

But I think the main issue with Bash (and maybe other shells), is that it’s parsed and run line by line. There’s nothing like a full script syntax check before the script is run, which most other languages provide as a bare minimum.

As one other comment mentioned, unfamiliarity with a particular language isn’t restricted to just bash. I could say the same for someone who only dabbles in C being made to read through Python. What’s this @decorator thing? Or what’s f"Some string: {variable}" supposed to do, and how’s memory being allocated here? It’s a domain, and we aren’t expected to know every single domain out there.

And your mention of losing typing and structure information is… ehh… somewhat of a weird argument. There are many cases where you don’t care about the contents of an output and only care about the process of spitting out that output being a success or failure, and that’s bread and butter in shell scripts. Need to move some files, either locally or over a network, bash is good for most cases. If you do need something just a teeny bit more, like whether some key string or pattern exists in the output, there’s grep. Need to do basic string replacements? sed or awk. Of course, all that depends on how familiar you or your teammates are with each of those tools. If nearly half the team are not, stop using bash right there and write it in something else the team’s familiar with, no questions there.

This is somewhat of an aside, but jq is actually pretty well-known and rather heavily relied upon at this point. Not to the point of say sqlite, but definitely more than, say, grep alternatives like ripgrep. I’ve seen it used quite often in deployment scripts, especially when interfaced with some system that replies with a json output, which seems like an increasingly common data format that’s available in shell scripting.

Always welcome a new shell. I’ve not heard of yash but I’ll check it out.

Any reason to use #!/bin/sh over #!/usr/bin/env sh?