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?

  • Badland9085@lemm.eeOP
    1·
    5 hours ago

    I honestly don’t care about being right or wrong. Our trade focuses on what works and what doesn’t and what can make things work reliably as we maintain them, if we even need to maintain them. I’m not proposing for bash to replace our web servers. And I certainly am not proposing that we can abandon robustness. What I am suggesting that we think about here, is that when you do not really need that robustness, for something that may perhaps live in your production system outside of user paths, perhaps something that you, your team, and the stakeholders of the particular project understand that the solution is temporary in nature, why would Bash not be sufficient?

    I suspect you just haven’t used Bash enough to hit some of the many many footguns.

    Wrong assumption. I’ve been writing Bash for 5-6 years now.

    Maybe it’s the way I’ve been structuring my code, or the problems I’ve been solving with it, in the last few years after using shellcheck and bash-language-server that I’ve not ran into issues where I get fucked over by quotes.

    But I can assure you that I know when to dip and just use a “proper programming language” while thinking that Bash wouldn’t cut it. You seem to have an image of me just being a “bash glorifier”, and I’m not sure if it’ll convince you (and I would encourage you to read my other replies if you aren’t), but I certainly don’t think bash should be used for everything.

    No. If it’s missing $1 will silently become an empty string. os.args[1] will throw an error. Much more robust.

    You’ll probably hate this, but you can use set -u to catch unassigned variables. You should also use fallbacks wherever sensible.

    Absolutely not. Python is strongly typed, and even statically typed if you want. Light years ahead of Bash’s mess. Quoting is pretty easy to get right in Python.

    Not a good argument imo. It eliminates a good class of problems sure. But you can’t eliminate their dependence on shared libraries that many commands also use, and that’s what my point was about.

    And I’m sure you can find a whole dictionary’s worth of cases where people shoot themselves in the foot with bash. I don’t deny that’s the case. Bash is not a good language where the programmer is guarded from shooting themselves in the foot as much as possible. The guardrails are loose, and it’s the script writer’s job to guard themselves against it. Is that good for an enterprise scenario, where you may either blow something up, drop a database table, lead to the lost of lives or jobs, etc? Absolutely not. Just want to copy some files around and maybe send it to an internal chat for regular reporting? I don’t see why not.

    Bash is not your hammer to hit every possible nail out there. That’s not what I’m proposing at all.

    • FizzyOrange@programming.dev
      1·
      2 hours ago

      And I certainly am not proposing that we can abandon robustness.

      If you’re proposing Bash, then yes you are.

      You’ll probably hate this, but you can use set -u to catch unassigned variables.

      I actually didn’t know that, thanks for the hint! I am forced to use Bash occasionally due to misguided coworkers so this will help at least.

      But you can’t eliminate their dependence on shared libraries that many commands also use, and that’s what my point was about.

      Not sure what you mean here?

      Just want to copy some files around and maybe send it to an internal chat for regular reporting? I don’t see why not.

      Well if it’s just for a temporary hack and it doesn’t matter if it breaks then it’s probably fine. Not really what is implied by “production” though.

      Also even in that situation I wouldn’t use it for two reasons:

      1. “Temporary small script” tends to smoothly morph into “10k line monstrosity that the entire system depends on” with no chance for rewrites. It’s best to start in a language that can cope with it.
      2. It isn’t really any nicer to use Bash over something like Deno. Like… I don’t know why you ever would, given the choice. When you take bug fixing into account Bash is going to be slower and more painful.