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?

  • @[email protected]
    2•9 hours ago

    Run checkbashisms over your $PATH (grep for #!/bin/sh). That’s the problem with Bash.
    #!/bin/sh is for POSIX compliant shell scripts only, use #!/bin/bash if you use bash syntax.

    Btw, i quite like yash.

    • @FooBarrington
      1•9 hours ago

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

      • @[email protected]English
        1•3 hours ago

        #!/usr/bin/env sh

        You want to use a /usr/bin command to find a /bin command?

        Do you know why /usr/bin and /bin aren’t the same, and why you should never rely on a /usr/{s,}bin where you’d be selecting for a /{s,}bin command? (and how, in trying to eradicate /usr, Lennart proved his reach exceeded his grasp?)

        • @FooBarrington
          1•2 hours ago

          You want to use a /usr/bin command to find a /bin command?

          Yes, why not? I’d rather always use env, than using it for some scripts and forgetting it for others…

          Do you know why /usr/bin and /bin aren’t the same, and why you should never rely on a /usr/{s,}bin where you’d be selecting for a /{s,}bin command?

          Do you know of any modern Linux where you can’t rely on /usr/bin/env existing? Your mini-rant about Poettering doesn’t inspire confidence that you have practical reasons.

      • @[email protected]
        1•8 hours ago

        I personally don’t see the point in using the absolute path to a tool to look up the relative path of your shell, because shell is always /bin/sh but the env binary might not even exist.

        Maybe use it with bash, some BSD’s or whatever might have it in /usr without having /bin symlinked to /usr/bin.

        • @[email protected]OP
          1•2 hours ago

          There are times when doing so does make sense, eg if you need the script to be portable. Of course, it’s the least of your worries in that scenario. Not all systems have bash being accessible at /bin like you said, and some would much prefer that you use the first bash that appears in their PATH, e.g. in nix.

          But yeah, it’s generally pretty safe to assume /bin/sh will give you a shell. But there are, apparently, distributions that symlink that to bash, and I’ve even heard of it being symlinked to dash.

          • @[email protected]
            1•4 minutes ago

            Not all systems have bash being accessible at /bin like you say

            Yeah, but my point is, neither match they /usr/bin/env. Bash, ok; but POSIX shell and Python, just leave it away.

            and I’ve even heard of it being symlinked to dash.

            I think Debian and Ubuntu do that (or one of them). And me too on Artix, there’s dash-as-bin-sh in AUR, a pacman hook that symlinks. Nothing important breaks by doing so.