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?

  • MajorHavoc
    123·
    1 hour ago

    A few responses for you:

    • I deeply despise bash (edit: this was hyperbole. I also deeply appreciate bash, as is appropriate for something that has made my life better for free!). That Linux shell defaults settled on it is an embarrassment to the entire open source community. (Edit: but Lexers and Parsers are hard! You don’t see me fixing it, so yes, I’ll give it a break. I still have to be discerning for production use, of course.)
    • Yes, Bash is good enough for production. It is the world’s current default shell. As long as we avoid it’s fancier features (which all suck for production use), a quick bash script is often the most reasonable choice.
    • For the love of all that is holy, put your own personal phone number and no one else’s in the script, if you choose to use bash to access a datatbase. There’s thousands of routine ways that database access can hiccup, and bash is suitable to help you diagnose approximately 0% of them.
    • If I found out a colleague had used bash for database access in a context that I would be expected to co-maintain, I would start by plotting their demise, and then talk myself down to having a severe conversation with them - after I changed it immediately to something else, in production, ignoring all change protocols. (Invoking emergency change protocols.)

    Edit: I can’t even respond to the security concerns aspect of this. Choice of security tool affects the quality of protection. In this unfortunate analogy, Bash is “the pull out method”. Don’t do that anywhere that it matters, or anywhere that one can be fired for security violations.

    (Edit 2: Others have mentioned invoking SQL DB cleanup scripts from bash. I have no problem with that. Letting bash or cron tell the DB and a static bit of SQL to do their usual thing has been fine for me, as well. The nightmare scenario I was imagining was bash gathering various inputs to the SQL and then invoking them. I’ve had that pattern blow up in my face, and had a devil of a time putting together what went wrong. It also comes with security concerns, as bash is normally a completely trusted running environment, and database input often come from untrusted sources.)

      • MajorHavoc
        5·
        7 hours ago

        I actually (also) love bash, and use it like crazy.

        What I really hate is that bash is so locked in legacy that it’s bad features (on a scripting language scale, which isn’t fair) (and of which there are too many to enumerate) are now locked in permanently.

        I also hate how convention has kept other shells from replacing bash’s worst features with better modern alternatives.

        To some extent, I’m railing against how hard it is to write a good Lexer and a Parser, honestly. Now that bash is stable, there’s little interest in improving it. Particularly since one can just invoke a better scripting language for complex work.

        I mourn the sweet spot that Perl occupies, that Bash and Python sit on either side of, looking longingly across the gap that separated their practical use cases.

        I have lost hope that Python will achieve shell script levels of pragmatism. Although the invoke library is a frigging cool attempt.

        But I hold on to my sorrow and anger that Bash hasn’t bridged the gap, and never will, because whatever it can invoke, it’s methods of responding to that invocation are trapped in messes like “if…fi”.

        • Badland9085@lemm.eeOP
          2·
          6 hours ago

          What do you suppose bash could do here? When a program reaches some critical mass in terms of adoption, all your bugs and features are features of your program, and, love it or hate it, somebody’s day is going to be ruined if you do your bug fixes, unless, of course, it’s a fix for something that clearly doesn’t work in the very sense of the word.

          I’m sure there’s space for a clear alternative to arise though, as far as scripting languages go. Whether we’ll see that anytime soon is hard to tell, cause yeah, a good lexer and parser in the scripting landscape is hard work.

          • MajorHavoc
            2·
            6 hours ago

            What do you suppose bash could do here?

            • For the love of all that is holy, it’s not 1970, we don’t need to continue to tolerate “if … fi”
            • Really everything about how bash handles logic bridging multiple lines of a file. (loops, error handling, etc)

            I’m sure there’s space for a clear alternative to arise though, as far as scripting languages go.

            The first great alternative/attempt does exist, in PowerShell. (Honorable mention to Zsh, but I find it has most of the same issues as bash without gaining the killer features of pwsh.)

            But I’m a cranky old person so I despise (and deeply appreciate!) PowerShell for a completely different set of reasons.

            At the moment I use whichever gets the job done, but I would love to stop switching quite so often.

            I hold more hope that PowerShell will grow to bridge the gap than that a fork of bash will. The big thing PowerShell lacks is bash’s extra decades of debugging and refinement.

      • MajorHavoc
        2·
        5 hours ago

        Sure.

        I’ll pick on postgres because it’s popular. But I have found that most databases have a similar number of error codes.

        https://www.postgresql.org/docs/current/errcodes-appendix.html

        It’s not an specific error that’s the issue, it’s the sheer variety of ways things can go wrong, combined with bash not having been architected with the database access use case in mind.

        • Badland9085@lemm.eeOP
          1·
          1 hour ago

          I find this argument somewhat weak. You are not going to run into the vast majority of those errors (in fact, some of them are not even errors, and you will probably never run into some of those errors as Postgres will not return them, eg some error codes from the sql standard). Many of them will only trigger if you do specific things: you started a transaction, you’ll have to handle the possible errors that comes with having a transaction.

          There are lots of reasons to never use bash to connect to a db to do things. Here are a couple I think of that I think are fairly basic that some may think they can just do in bash.

          • Write to more than 1 table.
          • Write to a table that has triggers, knowing that you may get a trigger failure.
          • Use transactions.
          • Calling a stored procedure that will raise exceptions.
          • Accepting user input to write that into a table.

          One case that I think is fine to use bash and connect to a db is when all you need to do a SELECT. You can test your statement in your db manager of choice, and bring that into bash. If you need input sanitization to filter results, stop, and use a language with a proper library. Otherwise, all the failure cases I can think of are: a) connection fails for whatever reason, in which case you don’t get your data, you get an exit code of 1, log to stderr, move on, b) your query failed cause of bad sql, in which case, well, go back to your dev loop, no?

          This is why I asked what sort of problems have you ran into before, assuming you haven’t been doing risky things with the connection. I’m sorry, but I must say that I’m fairly disappointed by your reply.