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.

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.

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.

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!

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.

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 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.

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.

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.)

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 for mkdir -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.