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?
Honestly, if a script grows to more than a few tens of lines I’m off to a different scripting language because I’ve written enough shell script to know that it’s hard to get right.
Shellcheck is great, but what’s greater is a language that doesn’t have as many gotchas from the get go.
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.
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.
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 …
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.
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)
I think I mentioned it, but inverse: The only data type I’m comfortable with in bash are simple string scalars; plus some simple integer handling I suppose. Once I have to think about stuff like
"${foo[@]}"and the like I feel like I should’ve switched languages already.Plus I rarely actually want arrays, it’s way more likely I want something in the shape of
@dataclass(frozen=True) class Foo: # … foos: set[Foo] = …I use the same heuristic… if I need a hashmap or more complex math, I need a different language
Also if the script grows beyond 100 lines, I stop and think about what I’m doing. Sometimes it’s OK, but it’s a warning flag
Yeah agreed on the 100 lines, or some other heuristic in the direction of “this script will likely continue to grow in complexity and I should switch to a language that’s better suited to handle that complexity”.
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.
Just make certain the robustness issues of bash do not have security implications. Variable, shell, and path evalutions can have security issues depending on the situation.
Certainly so. The same applies to any languages we choose, no?
Bash is especially suseptable. Bash was intended to be used only in a secure environment including all the inputs and data that is processed and including all the proccess on the system containing the bash process in question for that matter. Bash and the shell have a large attack surface. This is not true for most other languages. It is also why SUID programs for example should never call the shell. Too many escape options.
Good point. It’s definitely something to keep in mind about. It’s pretty standard procedure to secure your environments and servers, wherever arbitrary code can be ran, lest they become grounds for malicious actors to use your resources for their own gains.
What could be a non-secure environment where you can run Bash be like? A server with an SSH port exposed to the Internet with just password authentication is one I can think of. Are there any others?
By the way, I would not consider logging in via ssh and running a bash script to be insecure in general.
However taking uncontrolled data from outside of that session and injecting it could well be insecure as the data is probably crossing an important security boundary.
I was more thinking of the CGI script vunerability that showed up a few years ago. In that case data came from the web into the shell environment uncontrolled. So uncontrolled data processing where the input data crosses security boundaries is an issue kind of like a lot of the SQL injection attacks.
Another issue with the shell is that all proccesses on the system typically see all command line arguments. This includes any commands the shell script runs. So never specify things like keys or PII etc as command line arguments.
Then there is the general robustness issue. Shell scripts easy to write to run in a known environment and known inputs. Difficult to make general. So for fixed environment and known and controlled inputs that do not cross security boundaries probaby fine. Not that, probablay a big issue.
By the way, I love bash and shell scripts.
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.
As I’ve matured in my career, I write more and more bash. It is absolutely appropriate for production in the right scenarios. Just make sure the people who might have to maintain it in the future won’t come knocking down your door with torches and pitchforks…
That’s my take on the use of bash too. If it’s something that people think it’s worth bring their pitchforks out for, then it’s something you should probably not write in bash.
Dude, pihole is bash.
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?
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
What gave you the impression that this was just for development? Bash is widely used in production environments for scripting all over enterprises. The people you work with just don’t have much experience at lots of shops I would think.
It’s just not wise to write an entire system in bash. Just simple little tasks to do quick things. Yes, in production. The devops world runs on bash scripts.
Bash is widely used in production environments for scripting all over enterprises.
But it shouldn’t be.
The people you work with just don’t have much experience at lots of shops I would think.
More likely they do have experience of it and have learnt that it’s a bad idea.
I’ve never had that impression, and I know that even large enterprises have Bash scripts essentially supporting a lot of the work of a lot of their employees. But there are also many very loud voices that seems to like screaming that you shouldn’t use Bash almost at all.
You can take a look at the other comments to see how some are entirely turned off by even the idea of using bash, and there aren’t just a few of them.
This Lemmy thread isn’t representative of the real world. I’ve been a dev for 40 years. You use what works. Bash is a fantastic scripting tool.
I understand that. I have coworkers with about 15-20 years in the industry, and they frown whenever I put a bash script out for, say, a purpose that I put in my example: self-contained, clearly defined boundaries, simple, and not mission critical despite handling production data, typically done in less than 100 lines of bash with generous spacing and comments. So I got curious, since I don’t feel like I’ve ever gotten a satisfactory answer.
Thank you for sharing your opinion!
My #1 rule for the teams I lead is “consistency”. So it may fall back to that. The standard where you work is to use a certain way of doing things so everyone becomes skilled at the same thing.
I have the same rule, but I always let a little bash slide here and there.
Pretty much all languages are middleware, and most of the original code was shell/bash. All new employees in platform/devops want to immediately push their preferred language, they want java and rust environments. It’s a pretty safe bet if they insist on using a specific language; then they don’t know how awk or sed. Bash has all the tools you need, but good developers understand you write libraries for functionality that’s missing. Modern languages like Python have been widely adopted and has a friendlier onboarding and will save you time though.
Saw this guy’s post in another thread, he’s strawmanning because of lack of knowledge.
Pretty much all languages are middleware, and most of the original code was shell/bash.
What? I genuinely do not know what you mean by this.
2 parts:
- All languages are middleware. Unless you write in assembly, whatever you write isn’t directly being executed, they are being run through a compiler and being translated from your “middle language” or into 0s and 1s the computer can understand. Middleware is code used in between libraries to duplicate their functionality.
https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-middleware/ - Most original code was written in shell. Most scripting is done in the cli or shell language and stored as a
script.shfile, containing instructions to execute tasks. Before python was invented you used the basic shell because nothing else existed yet
The first part is confusing what “middleware” means. Rather than “duplicating” functionality, it connects libraries (I’m guessing this is what you meant). But that has nothing to do with a language being compiled versus “directly executed”, because compilation doesn’t connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of “middleware” between interpreted code and the operating system, but middleware typically doesn’t describe anything so critical to a piece of software that the software can’t run without it, so even that isn’t really a correct use of the term.
The second part is just…completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. “Most original code” is in an actual systems language like C.
(As a side note, Python wasn’t the first scripting language, and it didn’t become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)
You are stuck on 100% accuracy and trying to actually stuff to death. The user asked if it’s possible to write an application in bash and the answer is an overwhelming duh. Most assembly languages are emulators and they all predate C. You are confidant, wrong and loud. Guess I struck a nerve when I called you out for needing a specific language.
In addition to not actually being correct, I don’t think the information you’ve provided is particularly helpful in answering OP’s question.
- All languages are middleware. Unless you write in assembly, whatever you write isn’t directly being executed, they are being run through a compiler and being translated from your “middle language” or into 0s and 1s the computer can understand. Middleware is code used in between libraries to duplicate their functionality.
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?”
The nice thing about Powershell is that it was built basically now after learning all the things that previous shells left out. I’m not fluent in it, but as a Bash aficionado, I marveled at how nice it was at a previous job where we used it.
That said, I love Bash and use it for lots of fun automation. I think you’re right to appreciate it as you do. I have no opinion on the rest.
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 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.
We have dozens of bash scripts running table cleanups and maintenece tasks on the db. In the last 20 years these scripts where more stable than the database itself (oracle -> mysql -> postgres).
But in all fairness they just call the cliclient with the appropiate sql and check for the response code, generating a trap.
That’s a great point.
I post long enough responses already, so I didn’t want to get into resilience planning, but your example is a great highlight that there’s rarely hard and fast rules about what will work.
There certainly are use cases for bash calling database code that make sense.
I don’t actually worry much when it’s something where the first response to any issue is to run it again in 15 minutes.
It’s cases where we might need to do forensic analysis that bash plus SQL has caused me headaches.
Yeah, if it feels like a transaction would be helpful, at least go for pl/sql and save yourself some pain. Bash is for system maintenance, not for business logic.
Heck, I wrote a whole monitoring system for a telephony switch with nothing more than bash and awk and it worked better than the shit from the manufacturer, including writing to the isdn cards for mobile messaging. But I wouldn’t do that again if I have an alternative.
Bash is for system maintenance, not for business logic.
That is such a good guiding principle. I’m gonna borrow that.
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.
“Use the best tool for the job, that the person doing the job is best at.” That’s my approach.
I will use bash or python dart or whatever the project uses.
