this post was submitted on 15 Jan 2025
82 points (97.7% liked)

Programming

17831 readers
602 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

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
82
Am I crazy in thinking that bash is good enough for production? (lemm.ee)
submitted 2 days ago by Badland9085@lemm.ee to c/programming@programming.dev
122 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?

you are viewing a single comment's thread
view the rest of the comments
[–] FizzyOrange@programming.dev 1 points 5 hours ago

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.

Yes, because that is precisely the case. It's not a personal attack, it's just a fact that Bash is not robust.

You're trying to argue that your cardboard bridge is perfectly robust and then getting offended that I don't think you should let people drive over it.

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.

You mean "third party libraries" not "shared libraries". But anyway, so what? I don't see what that has to do with this conversation. Do your Bash scripts not use third party code? You can't do a lot with pure Bash.

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.

Well that's why I don't use Bash. I'm not blaming it for existing, I'm just saying it's shit so I don't use it.

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.

Handling errors correctly is slightly more code ("boilerplate") than letting everything break when something unexpected happens. I hope you aren't trying to use that as a reason not to handle errors properly. In any case the extra boilerplate is... Deno.env.get("FOO"). Wow.

What’s the syntax for mkdir? What’s it for mkdir -p? What about other options?

await Deno.mkdir("foo");
await Deno.mkdir("foo", { recursive: true });

What's the syntax for a dictionary in Bash? What about a list of lists of strings?