Am I crazy in thinking that bash is good enough for production? (lemm.ee)

submitted 4 days ago by Badland9085@lemm.ee to c/programming@programming.dev

121 comments fedilink hide all child comments

This may make some people pull their hair out, but I’d love to hear some arguments. I’ve had the impression that people really don’t like bash, not from here, but just from people I’ve worked with.

There was a task at work where we wanted something that’ll run on a regular basis, and doesn’t do anything complex aside from reading from the database and sending the output to some web API. Pretty common these days.

I can’t think of a simpler scripting language to use than bash. Here are my reasons:

Reading from the environment is easy, and so is falling back to some value; just do ${VAR:-fallback}; no need to write another if-statement to check for nullity. Wanna check if a variable’s set to something expected? if [[ <test goes here> ]]; then <handle>; fi
Reading from arguments is also straightforward; instead of a import os; os.args[1] in Python, you just do $1.
Sending a file via HTTP as part of an application/x-www-form-urlencoded request is super easy with curl. In most programming languages, you’d have to manually open the file, read them into bytes, before putting it into your request for the http library that you need to import. curl already does all that.
Need to read from a curl response and it’s JSON? Reach for jq.
Instead of having to set up a connection object/instance to your database, give sqlite, psql, duckdb or whichever cli db client a connection string with your query and be on your way.
Shipping is… fairly easy? Especially if docker is common in your infrastructure. Pull Ubuntu or debian or alpine, install your dependencies through the package manager, and you’re good to go. If you stay within Linux and don’t have to deal with differences in bash and core utilities between different OSes (looking at you macOS), and assuming you tried to not to do anything too crazy and bring in necessary dependencies in the form of calling them, it should be fairly portable.

Sure, there can be security vulnerability concerns, but you’d still have to deal with the same problems with your Pythons your Rubies etc.

For most bash gotchas, shellcheck does a great job at warning you about them, and telling how to address those gotchas.

There are probably a bunch of other considerations but I can’t think of them off the top of my head, but I’ve addressed a bunch before.

So what’s the dealeo? What am I missing that may not actually be addressable?

(page 3) 21 comments

sorted by: hot top controversial new old

[-] onlinepersona@programming.dev -1 points 4 days ago

May I introduce you to rust script? Basically a wrapper to run rust scripts right from the command line. They can access the rust stdlib, crates, and so on, plus do error handling and much more.

Anti Commercial-AI license

[-] Ephera@lemmy.ml 0 points 4 days ago

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.

[-] onlinepersona@programming.dev -1 points 4 days ago

Defining run is definitely the quick way to do it 👍 I'd love to have a proc macro that takes a bash like syntax e.g someCommand | readsStdin | processesStdIn > someFile and builds the necessary rust to use. xonsh does it using a superset of python, but I never really got into it.

Anti Commercial-AI license

load more comments (2 replies)

[-] Badland9085@lemm.ee 0 points 4 days ago

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?

[-] onlinepersona@programming.dev -1 points 4 days ago

I'd use clap, yeah. And env vars std::env::var("MY_VAR")? You can of course start writing your own macro crate. I wouldn't be surprised if someone already did write a proc macro crate that introduces its own syntax to make calling subprocesses easier. The shell is.. your oyster 😜

Anti Commercial-AI license

[-] Badland9085@lemm.ee 0 points 4 days ago

I can only imagine that macro crate being a nightmare to read and maintain given how macros are still insanely hard to debug last I heard (might be a few years ago now).

[-] onlinepersona@programming.dev -1 points 4 days ago

proc macros can be called in tests and debugged. They aren't that horrible, but can be tedious to work with. A good IDE makes it a lot easier though, that's for sure.

Anti Commercial-AI license

load more comments (2 replies)

[-] GammaGames@beehaw.org 0 points 4 days ago* (last edited 4 days ago)

I agree with your points, except if the script ever needs maintaining by someone else’s they will curse you and if it gets much more complicated it can quickly become spaghetti. But I do have a fair number of bash scripts running on cron jobs, sometimes its simplicity is unbeatable!

Personally though the language I reach for when I need a script is Python with the click library, it handles arguments and is really easy to work with. If you want to keep python deps down you can also use the sh module to run system commands like they’re regular python, pretty handy

[-] Badland9085@lemm.ee 0 points 4 days ago

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.

[-] MajorHavoc@programming.dev 0 points 4 days ago* (last edited 4 days ago)

That said, I don’t necessarily agree that bash is bad from a maintainability standpoint.

My team uses bash all the time, but we agree (internally as a team) that bash is bad from a maintainability perspective.

As with any tool we use, some of us are experts, and some are not. But the non-experts need tools that behave themselves on days when experts are out of office.

We find that bash does very well when each entire script has no need for branching logic, security controls, or error recovery.

So we use substantial amounts of bash in things like CI/CD pipelines.

load more comments (1 replies)

[-] 7uWqKj@lemmy.world 0 points 4 days ago

Bash is perfectly good for what you’re describing.

[-] MajorHavoc@programming.dev 0 points 4 days ago

Serious question (as a bash complainer):

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

[-] 7uWqKj@lemmy.world 0 points 4 days ago

Every database I know comes with an SQL shell that takes commands from stdin and writes query results to stdout. Remember that "bash" never means bash alone, but all the command line tools from cut via jq to awk and beyond … so, that SQL shell would be what you call "bash library".

load more comments (2 replies)

load more comments

this post was submitted on 15 Jan 2025

29 points (96.8% liked)

Programming

17845 readers

33 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz