Programming @programming.dev Badland9085 @lemm.ee 4d ago

Am I crazy in thinking that bash is good enough for production?

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?

132

You're viewing part of a thread.

Show Context

132 comments

Sure, but iirc posix also suggests you should set the proper path on installing the script. Protecting yourself from assuming /bin/sh exists by assuming /usr/bin/env exists isn't really a win.

The env trick makes sense for bash sometimes as you might not have the right to upgrade /bin/bash but you might want a more modern bash version. Bash and other shells enter a special compatibility mode when started as sh though so apart from bugs getting fixed, running a newer version of bash for your sh needs shouldn't really get you anything in the way of features. Making sh path dependent is thus a bit weird
- I've seen enough scripts that use /bin/sh while using non-standard features, to appreciate not having to set up a completely new environment to override it. As an example, I had scripts written by a Mac user that used the /bin/sh shebang, but didn't run with dash. I had to rewrite all the shebangs to point them at bash instead, wouldn't have had to do that with a better shebang.
  
  A sh script using non standard features should probably be fixed, not overridden. If you want it to be a sh script for compatibility, you have to restrict yourself to posix features and probably test in a bunch of shells. If the script was really written for bash and that's ok, giving it the bash shebang is the correct thing to do.
  
  Well, I'd rather run a script using an overriden /bin/sh than going through and fixing every one-time script I get from someone else. Do you really have the time for that?
  
  I've never seen any #!/usr/bin/env sh in the wild so I'd be surprised if you save any time that way.
  
  If you want people to start using env to launch sh because it makes it easier for you to workaround them really writing a bash, dash, zsh, whatever script and pretending it's sh, it would be better to ask them to use env to launch bash, dash or zsh etc.
  
  Of course I save time if the script already has that shebang? Not sure what you're trying to say.
  
  And obviously it would be better if the script wasn't wrong, but it's easier for me to advocate for "always use env" than "always do the right thing"
  
  So the scenario is that you'll get shell scripts that incorrectly use #!/usr/bin/env sh when they really depend on say zsh, and your solution is to make sure zsh is first in your path?
  
  And then you get another broken script like that which depends on bash, what do you do then?
  
  And this fiddling with your path is easier for you than just fixing the broken shebang?
  
  I'm not sure what's so hard to understand. I sometimes encounter scripts that use #!/bin/sh when they use non-POSIX features. If those scripts used env, it would be easy for me to change the resolved shell while invoking this script (and consequently sub-scripts).
  
  Why are you acting like this is a crazy complicated idea? Why are you acting like overriding sh for a single invocation is more work than touching the shebangs of n script files?

132 comments