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-urlencodedrequest is super easy withcurl. 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.curlalready does all that. - Need to read from a
curlresponse and it’s JSON? Reach forjq. - Instead of having to set up a connection object/instance to your database, give
sqlite,psql,duckdbor 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
Ubuntuordebianoralpine, 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?
We are not taking about use of Bash in dev vs use Bash in production. This is imho incorrect question that skirts around the real problem in software development. We talk about use of Bash for simple enough tasks where code is rarely changed ( if not written once and thrown away ) and where every primitive language or DSL is ok, where when it comes to building of medium or complex size software systems where decomposition, complex data structures support, unit tests, error handling, concurrency, etc is a big of a deal - Bash really sucks because it does not allow one to deal with scaling challenges, by scaling I mean where you need rapidly change huge code base according changes of requirements and still maintain good quality of entire code. Bash is just not designed for that.
But not everything needs to scale, at least, if you don’t buy into the doctrine that everything has to be designed and written to live forever. If robust, scalable solutions is the nature of your work and there’s nothing else that can exist, then yeah, Bash likely have no place in that world. If you need any kind of handling more complicated than just getting an error and doing something else, then Bash is not it.
Just because Bash isn’t designed for something you want to do, doesn’t mean it sucks. It’s just not the right tool. Just because you don’t practice law, doesn’t mean you suck; you just don’t do law. You can say that you suck at law though.
Yep. Like said - “We talk about use of Bash for simple enough tasks … where every primitive language or DSL is ok”, so Bash does not suck in general and I myself use it a lot in proper domains, but I just do not use it for tasks / domains with complexity ( in all senses, including, but not limited to team work ) growing over time …
If your company ever has >2 people, it will become a problem.
You’re speaking prophetically there and I simply do not agree with that prophecy.
If you and your team think you need to extend that bash script to do more, stop and consider writing it in some other languages. You’ve move the goalpost, so don’t expect that you can just build on your previous strategy and that it’ll work.
If your “problem” stems from “well your colleagues will not likely be able to read or write bash well enough”, well then just don’t write it in bash.
One thing that I don’t think anyone else has mentioned is data structures. Bash does have arrays and hashmaps at least but I’ve found that working with them is significantly more awkward than in e.g. python. This is one of several reasons for why bash doesn’t scale up well, but sure for small enough scripts it can be fine (if you don’t care about windows)
That’s definitely worth mentioning indeed. Bash variables, aside from arrays and hashmaps that you get with
declare, are just strings. Any time you need to start capturing a group of data and do stuff with them, it’s a sign to move on. But there are many many times where that’s unnecessary.
I’ve worked in bash. I’ve written tools in bash that ended up having a significant lifetime.
Personally, you lost me at
reading from the database
Database drivers exist for a reason. Shelling out to a database cli interface is full of potential pitfalls that don’t exist in any language with a programmatic interface to the database. Dealing with query parameterization in bash sounds un-fun and that’s table stakes, security-wise.
Same with making web API calls. Error handling in particular is going to require a lot of boilerplate code that you would get mostly for free in languages like Python or Ruby or Go, especially if there’s an existing library that wraps the API you want to use in native language constructs.
This is almost a strawman argument.
You don’t have to shell out to a db cli. Most of them will gladly take some SQL and spit out some output. Now that output might be in some tabular format with some pretty borders around them that you have to deal with, if you are about the output within your script, but that’s your choice and so deal with it if it’s within your comfort zone to do so. Now if you don’t care about the output and just want it in some file, that’s pretty straightforward, and it’s not too different from just some cli that spits something out and you’ve redirected that output to a file.
I’ve mentioned in another comment where if you need to accept input and use that for your queries, psql is absolutely not the tool to use. If you can’t do it properly in bash and tools, just don’t. That’s fine.
With web API calls, same story really; you may not be all that concerned about the response. Calling a webhook? They’re designed to be a fire and forget, where we’re fine with losing failed connections. Some APIs don’t really follow strict rules with REST, and will gladly include an “ok” as a value in their response to tell you if a request was successful. If knowing that is important to the needs of the program, then, well, there you have it. Otherwise, there are still ways you can get the HTTP code and handle appropriately. If you need to do anything complex with the contents of the response, then you should probably look elsewhere.
My entire post is not to say that “you can do everything in bash and you should”. My point is that there are many cases where bash seems like a good sufficient tool to get that simple job done, and it can do it more easily with less boilerplate than, say, Python or Ruby.
I’m fine with bash for ci/cd activities, for what you’re talking about I’d maybe use bash to control/schedule running of a script in something like python to query and push to an api but I do totally get using the tools you have available.
I use bash a lot for automation but PowerShell is really nice for tasks like this and has been available in linux for a while. Seen it deployed into production for more or less this task, grabbing data from a sql server table and passing to SharePoint. It’s more powerful than a shell language probably needs to be, but it’s legitimately one of the nicer products MS has done.
End of the day, use the right tool for the job at hand and be aware of risks. You can totally make web requests from sql server using ole automation procedures, set up a trigger to fire on update and send data to an api from a stored proc, if I recall there’s a reason they’re disabled by default (it’s been a very long time) but you can do it.
People have really been singing praises of Powershell huh. I should give that a try some time.
But yeah, we wield tools that each come with their own risks and caveats, and none of them are perfect for everything, but some are easier (including writing it and addressing fallovers for it) to use in certain situations than others.
It’s just hard to tell if people’s fear/disdain/disgust/insert-negative-reaction towards bash is rational or more… tribal, and why I decided to ask. It’s hard to shake away the feeling of “this shouldn’t just be me, right?”
I have to wonder if some of it is comfort or familiarity, I had a negative reaction to python the first time I ever tried it for example, hated the indent syntax for whatever reason.
Creature comfort is a thing. You’re used to it. Familiarity. You know how something behaves when you interact with it. You feel… safe. Fuck that thing that I haven’t ever seen and don’t yet understand. I don’t wanna be there.
People who don’t just soak in that are said to be, maybe, adventurous?
It can also be a “Well, we’ve seen what can work. It ain’t perfect, but it’s pretty good. Now, is there something better we can do?”
The indent syntax is one of the obviously bad decisions in the design of python so it makes sense
I’m afraid your colleagues are completely right and you are wrong, but it sounds like you genuinely are curious so I’ll try to answer.
I think the fundamental thing you’re forgetting is robustness. Yes Bash is convenient for making something that works once, in the same way that duct tape is convenient for fixes that work for a bit. But for production use you want something reliable and robust that is going to work all the time.
I suspect you just haven’t used Bash enough to hit some of the many many footguns. Or maybe when you did hit them you thought “oops I made a mistake”, rather than “this is dumb; I wouldn’t have had this issue in a proper programming language”.
The main footguns are:
- Quoting. Trust me you’ve got this wrong even with
shellcheck. I have too. That’s not a criticism. It’s basically impossible to get quoting completely right in any vaguely complex Bash script. - Error handling. Sure you can
set -e, but then that breaks pipelines and conditionals, and you end up with really monstrous pipelines full ofpipefailnoise. It’s also extremely easy to forgetset -e. - General robustness. Bash silently does the wrong thing a lot.
instead of a
import os; os.args[1]in Python, you just do$1No. If it’s missing
$1will silently become an empty string.os.args[1]will throw an error. Much more robust.Sure, there can be security vulnerability concerns, but you’d still have to deal with the same problems with your Pythons your Rubies etc.
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.
I actually started keeping a list of bugs at work that were caused directly by people using Bash. I’ll dig it out tomorrow and give you some real world examples.
I don’t disagree with your point, but how does
set -ebreak conditionals? I use it all the time without issuesPipefail I don’t use as much so perhaps that’s the issue?
It means that all commands that return a non-zero exit code will fail the script. The problem is that exit codes are a bit overloaded and sometimes non-zero values don’t indicate failure, they indicate some kind of status. For example in
git diff --exit-codeorgrep.I think I was actually thinking of
pipefailthough. If you don’t set it then errors in pipelines are ignored, which is obviously bad. If you do then you can’t usegrepin pipelines.My sweet spot is
set -uebecause I like to be able to use things likeif grep -q ...; thenand I like things to stop if I misspelled a variable.It does hide failures in the middle of a pipeline, but it’s a tradeoff. I guess one could turn it on and off when needed
Agreed.
Also gtfobins is a great resource in addition to shellcheck to try to make secure scripts.
For instance I felt upon a script like this recently:
#!/bin/bash # ... some stuff ... tar -caf archive.tar.bz2 "$@"Quotes are OK, shellcheck is happy, but, according to gtfobins, you can abuse tar, so running the script like this:
./test.sh /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/shends up spawning an interactive shell…So you can add up binaries insanity on top of bash’s mess.
I imagine adding
--so it becomestar -caf archive.tar.bz2 -- "$@"would fix that specific caseBut yeah, putting bash in a position where it has more rights than the user providing the input is a really bad idea
gtfobins
Meh, most in that list are just “if it has the SUID bit set, it can be used to break out of your security context”.
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
shellcheckandbash-language-serverthat 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
$1will 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 -uto 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.
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:
- “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.
- 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.
I’m going to downvote your comment based on that first quote reply, because I think that’s an extreme take that’s unwarranted. 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.
And judging by your second comment, I can see that you have very strong opinions against bash for reasons that I don’t find convincing, other than what seems to me like irrational hatred from being rather uninformed. It’s fine being uninformed, but I suggest you tame your opinions and expectations with that.
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.
If production only implies systems in a user’s path and not anything else about production data, then sure, my example is not production. That said though, I wouldn’t use bash for anything that’s in a user’s path. Those need to stay around, possible change frequently, and not go down. Bash is not your language for that and that’s fine. You’re attacking a strawman that you’ve constructed here though.
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. You’ve all failed to anticipate that change and misunderstood the “temporary” nature of your script, and allowed your “temporary thing” to become permanent. That’s a management issue, not a language choice. You’ve moved that goalpost and failed to change your strategy to hit that goal.
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. You have to get a library for, say, accessing contents in Azure or AWS, set that up, figure out how that api works, etc, while you could already do that with the awscli and probably already did it to check if you could get what you want. What’s the syntax for
mkdir? What’s it formkdir -p? What about other options? If you already use the terminal frequently, some of these are your basic bread and butter and you know them probably by heart. Unless you start doing that with Deno, you won’t reach the level of familiarity you can get with the shell (whichever shell you use ofc).And many argue against bash with regards to error handling. You don’t always need something that proper language has. You don’t always need to handle every possible error state differently, assuming you have multiple. Did it fail? Can you tolerate that failure? Yup? Good. No? Can you do something else to get what you want or make it tolerable? Yes? Good. No? Maybe you don’t want to use bash then.
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?
- Quoting. Trust me you’ve got this wrong even with
I just don’t think bash is good for maintaining the code, debugging, growing the code over time, adding automated tests, or exception handling
If you need anything that complex and that it’s critical for, say, customers, or people doing things directly for customers, you probably shouldn’t use bash. Anything that needs to grow? Definitely not bash. I’m not saying bash is what you should use if you want it to grow into, say, a web server, but that it’s good enough for small tasks that you don’t expect to grow in complexity.
it’s (bash) good enough for small tasks that you don’t expect to grow in complexity.
I don’t think you’ll get a lot of disagreement on that, here. As mention elsewhere, my team prefers bash for simple use cases (and as their bash-hating boss, I support and agree with how and when they use bash.)
But a bunch of us draw the line at database access.
Any database is going to throw a lot of weird shit at the bash script.
So, to me, a bash script has grown to unacceptable complexity on the first day that it accesses a database.
small tasks that you don’t expect to grow in complexity
On one conference I heard saying: “There is no such thing as temporary solution and there is no such thing as proof of concept”. It’s an overexaguration of course but it has some truth to it - there’s a high chance that your “small change” or PoC will be used for the next 20 years so write it as robust and resilient as possible and document it. In other words everything will be extended, everything will be maintained, everything will change hands.
So to your point - is bash production ready? Well, depends. Do you have it in git? Is it part of some automation pipeline? Is it properly documented? Do you by chance have some tests for it? Then yes, it’s production ready.
If you just “write this quick script and run it in cron” then no. Because in 10 years people will pull their hair screaming “what the hell is hapenning?!”
Edit: or worse, they’ll scream it during the next incident that’ll happen at 2 AM on Sunday
I find it disingenuous to blame it on the choice of bash being bad when goalposts are moved. Solutions can be temporary as long as goalposts aren’t being moved. Once the goalpost is moved, you have to re-evaluate whether your solution is still sufficient to meet new needs. If literally everything under the sun and out of it needs to be written in a robust manner to accommodate moving goalposts, by that definition, nothing will ever be sufficient, unless, well, we’ve come to a point where a human request by words can immediately be compiled into machine instructions to do exactly what they’ve asked for, without loss of intention.
That said, as engineers, I believe it’s our responsibility to identify and highlight severe failure cases given a solution and its management, and it is up to the stakeholders to accept those risks. If you need something running at 2am in the morning, and a failure of that process would require human intervention, then maybe you should consider not running it at 2am, or pick a language with more guardrails.
Run checkbashisms over your $PATH (grep for #!/bin/sh). That’s the problem with Bash.
is for POSIX compliant shell scripts only, useif you use bash syntax.Btw, i quite like yash.
Always welcome a new shell. I’ve not heard of yash but I’ll check it out.
Any reason to use
over?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.
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
/binlike you said, and some would much prefer that you use the first bash that appears in theirPATH, e.g. in nix.But yeah, it’s generally pretty safe to assume
/bin/shwill 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.Not all systems have bash being accessible at
/binlike you sayYeah, 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-shin AUR, a pacman hook that symlinks. Nothing important breaks by doing so.Leaving it away for Python? Are you mad? Why would you want to use my system Python instead of the one specified in my
PATH?
Over the last ten - fifteen years, I’ve written lots of scripts for production in bash. They’ve all served their purposes (after thorough testing) and not failed. Pretty sure one of my oldest (and biggest) is called
temporary_fixes.shand is still in use today. Another one (admittedly not in production) was partially responsible for getting me my current job, I guess because the interviewers wanted to see what kind of person would solve a coding challenge in bash.However, I would generally agree that - while bash is good for many things and perhaps even “good enough” - any moderately complex problem is probably better solved using a different language.
Well then you guys will love what this guy (by tha name “icitry”) did with bash https://www.youtube.com/watch?v=b_WGoPaNPMY
He created a youtube clone with Bash
That is definitely not something I would do… for work (totally not implying that I miiiight do it outside of work for shits and giggles :P).
I didn’t create this post trying to be like “y’all should just use Bash”, nor is it an attempt to say that I like Bash, but I guess that’s how people boil others down to these days. Fanatics only. Normalcy is dead. (I’m exaggerating ofc)
Basically, If you are crazy enough, you csn make anything with any language<br> Hence, me sharing the video
Wanna check if a variable’s set to something expected?
if [[ <test goes here> ]]; then <handle>; fiHey, you can’t just leave out “test goes here”. That’s worst part by a long shot.
The rest of the syntax, I will have to look up every time I try to write it, but at least I can mostly guess what it does when reading. The test syntax on the other hand is just impossible to read without looking it up.I also don’t actually know how to look that up for the double brackets, so that’s fun. For the single bracket, it took me years to learn that that’s actually a command and you can do
man [to view the documentation.To be fair, you don’t always have to use the
[[syntax. I know I don’t, e.g. if I’m just looking for a command that returns 1 or 0, which happens quite a bit if you get to usegrep.That said,
man testis my friend.But I’ve also gotten so used to using it that I remember
-zand-nby heart :PIf you need to use bash a lot just to learn 2 “keywords”, then it’s not a good language.
I have looked at bash scripts in the past, and even written some (small amount). I had to look up
-zand-nevery time. I’ve written a lot more python than bash, that’s for sure. But even if I don’t write python for a year, when needed I can just write an entire python script without minimal doc lookups. I just need to search if the function I want is part ofsyd,osorpath.The first time I want to do an
else ifmy IDE will mark it red and I’ll writeeliffrom then on, same thing if I try to use{}.If a bash script requires at least one array and one if statement, I can write the entire thing in python faster than I can search how to do those 2 things in bash.
To each their own really. You have what you’re familiar with, and I have mine. That said, I’m not proposing Bash as a good language. It is by no means that.
Now, to use Python for comparison. With a year of not using it, I’d be asking lots of questions. How do I
mkdir? How do Imkdir -p? What aboutcpormvand their flags? Did I use to bring in some library to make this less painful?Cause look, I already use many of these commands in the terminal, basically all the time cause I work in it.
Fwiw, there’s a
bash-language-serverthat can warn you of some syntactical errors.
Dude, pihole is bash.
I don’t disagree with this, and honestly I would probably support just using bash like you said if I was in a team where this was suggested.
I think no matter how simple a task is there are always a few things people will eventually want to do with it:
- Reproduce it locally
- Run unit tests, integration tests, smoke tests, whatever tests
- Expand it to do more complex things or make it more dynamic
- Monitor it in tools like Datadog
If you have a whole project already written in Python, Go, Rust, Java, etc, then just writing more code in this project might be simpler, because all the tooling and methodology is already integrated. A script might not be so present for many developers who focus more on the code base, and as such out of sight out of mind sets in, and no one even knows about the script.
There is also the consideration that many people simply dislike bash since it’s an odd language and many feel it’s difficult to do simple things with it.
due to these reasons, although I would agree with making the script, I would also be inclined to have the script temporarily while another solution is being implemented.
I don’t necessarily agree that all simple tasks will lead to the need for a test suite to accommodate more complex requirements. If it does reach that point,
- Your simple bash script has and is already providing basic value.
- You can (and should) move onto a more robust language to do more complicated things and bring in a test suite, all while you have something functional and delivering value.
I also don’t agree that you can just solder on whatever small task you have to whatever systems you already have up and running. That’s how you make a Frankenstein. Someone at some point will have to come do something about your little section because it started breaking, or causing other things to break. It could be throwing error messages because somebody changed the underlying db schema. It could be calling and retrying a network call and due to, perhaps, poorly configured backoff strategy, you’re tripping up monitoring alerts.
That said, I do agree on it suitable for temporary tasks.
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
bashto 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
bashgathering 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.)Why internet man hate Bash? Bash do many thing. Make computer work.
I actually (also) love
bash, and use it like crazy.What I really hate is that
bashis 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
invokelibrary 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”.
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.
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.
Could you explain those db connection hiccups you’ve seen?
Sure.
I’ll pick on
postgresbecause 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.
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.
This is why I asked what sort of problems have you ran into before,
Lol. I’m fucking old. I don’t remember details.
assuming you haven’t been doing risky things with the connection.
Ha! Not a safe assumption, though. I’ve maintained even more shitty code than I’ve written, and that’s a lot! Lol.
I find this argument somewhat weak.
Lol. Me too. I was just trying to give the shorthand version.
Your explanation is much better.
Edit: but it doesn’t sound like you really needed a detailed answer from me, anyway.
I actually love listening to or reading someone else’s war story, and tbh the entire purpose of this post is to dig those up. Bash is one of those places where a lot about it is passed around as tribal knowledge. So I’d really love to hear how things have failed.
Fair enough.
Here’s what I remember: invoking
SQLcontaining inserts frombashhas resulted in lost data, when fairly unsurprising database things happened, sincebashdidn’t really expect to be in charge of logging the details of the attempted change. For the error, it wasn’t something surprising - maybe it was “max connections reached”, stuff that will just happen sometimes.The data loss was probably solveable in
bash, but the scripter didn’t think to (and probably would have needed more effort in a full development tool).Seems like something that can happen in any languages, though yeah, bash doesn’t make it easier, and it’ll depend on what the cli tool would return given the error (eg does it return some code in stdout or stderr, or some non-zero exit code). Depending on the library (in the language of choice), you may still have to handle such errors manually, eg adding the necessary logic to retry.
And in such a case, I guess it would be prudent to either make sure that the data can be retrieved again, or push it somewhere a bit more permanent (shared fs, or object storage), sort of in a dead-letter-esque style. Seems like the lesson here is to have a fall over plan. The failure mode is not something a proper language and library would necessarily help discover more easily though.
- I deeply despise
It’s ok for very small scripts that are easy to reason through. I’ve used it extensively in CI/CD, just because we were using Jenkins for that and it was the path of least resistance. I do not like the language though.
Bash is perfectly good for what you’re describing.
Serious question (as a bash complainer):
Have I missed an amazing bash library for secure database access that justifies a “perfectly good” here?
Every database I know comes with an SQL shell that takes commands from stdin and writes query results to stdout. Remember that “bash” never means bash alone, but all the command line tools from cut via jq to awk and beyond … so, that SQL shell would be what you call “bash library”.
Thank you. I wasn’t thinking about that. That’s a great point.
As long as any complex recovery logic fits inside the SQL, itself, I don’t have any issue invoking it from
bash.It’s when there’s complicated follow-up that needs to happen in bash that I get anxious about it, due to past painful experiences.
Right, that’s when you should look for a driver language that’s better suited for the job, e. g. Python.
