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?
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 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
A few responses for you:
- I deeply despise
bash. That Linux shell defaults settled on it is an embarrassment to the entire open source community. - 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.
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.
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).
- 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.
May I introduce you to rust script? Basically a wrapper to run rust scripts right from the command line. They can access the rust stdlib, crates, and so on, plus do error handling and much more.
How easily can you start parsing arguments and read env vars? Do people import clap and such to provide support for those sorts of needs?
I’d use clap, yeah. And env vars
std::env::var("MY_VAR")?You can of course start writing your own macro crate. I wouldn’t be surprised if someone already did write a proc macro crate that introduces its own syntax to make calling subprocesses easier. The shell is… your oyster 😜I can only imagine that macro crate being a nightmare to read and maintain given how macros are still insanely hard to debug last I heard (might be a few years ago now).
Check out @Ephera@lemmy.ml’s comment with existing libraries. Someone already did the work! 🎉
I’m so glad we have madlads in rust land xD Thanks for referring me to that!
proc macros can be called in tests and debugged. They aren’t that horrible, but can be tedious to work with. A good IDE makes it a lot easier though, that’s for sure.
Yeah, sometimes I’ll use that just to have the sane control flow of Rust, while still performing most tasks via commands.
You can throw down a function like this to reduce the boilerplate for calling commands:
fn run(command: &str) { let status = Command::new("sh") .arg("-c") .arg(command) .status() .unwrap(); assert!(status.success()); }Then you can just write
run("echo 'hello world' > test.txt");to run your command.Defining
runis definitely the quick way to do it 👍 I’d love to have a proc macro that takes a bash like syntax e.gsomeCommand | readsStdin | processesStdIn > someFileand builds the necessary rust to use. xonsh does it using a superset of python, but I never really got into it.Wow, that’s exactly what I was looking for! Thanks dude.
Basically a wrapper to run rust scripts right from the command line.
Isn’t that just Python? :v
“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.
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 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 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 extendended, 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?!”
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.
I agree with your points, except if the script ever needs maintaining by someone else’s they will curse you and if it gets much more complicated it can quickly become spaghetti. But I do have a fair number of bash scripts running on cron jobs, sometimes its simplicity is unbeatable!
Personally though the language I reach for when I need a script is Python with the click library, it handles arguments and is really easy to work with. If you want to keep python deps down you can also use the sh module to run system commands like they’re regular python, pretty handy
Those two libraries actually look pretty good, and seems like you can remove a lot of the boilerplate-y code you’d need to write without them. I will keep those in mind.
That said, I don’t necessarily agree that bash is bad from a maintainability standpoint. In a team where it’s not commonly used, yeah, nobody will like it, but that’s just the same as nobody would like it if I wrote in some language the team doesn’t already use? For really simple, well-defined tasks that you make really clear to stakeholders that complexity is just a burden for everyone, the code should be fairly simple and straightforward. If it ever needs to get complicated, then you should, for sure, ditch bash and go for a larger language.
That said, I don’t necessarily agree that bash is bad from a maintainability standpoint.
My team uses bash all the time, but we agree (internally as a team) that bash is bad from a maintainability perspective.
As with any tool we use, some of us are experts, and some are not. But the non-experts need tools that behave themselves on days when experts are out of office.
We find that bash does very well when each entire script has no need for branching logic, security controls, or error recovery.
So we use substantial amounts of bash in things like CI/CD pipelines.
Hell, I hate editing bash scripts I’ve written. The syntax just isn’t as easy
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.
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.
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.
In your own description you added a bunch of considerations, requirements of following specific practices, having specific knowledge, and a ton of environmental requirements.
For simple scripts or duck tape schedules all of that is fine. For anything else, I would be at least mindful if not skeptical of bash being a good tool for the job.
Bash is installed on all linux systems. I would not be very concerned about some dependencies like sqlite, if that is what you’re using. But very concerned about others, like jq, which is an additional tool and requirement where you or others will eventually struggle with diffuse dependencies or managing a managed environment.
Even if you query sqlite or whatever tool with the command line query tool, you have to be aware that getting a value like that into bash means you lose a lot of typing and structure information. That’s fine if you get only one or very few values. But I would have strong aversions when it goes beyond that.
You seem to be familiar with Bash syntax. But others may not be. It’s not a simple syntax to get into and intuitively understand without mistakes. There’s too many alternatives of if-ing and comparing values. It ends up as magic. In your example, if you read code, you may guess that
:-means fallback, but it’s not necessarily obvious. And certainly not other magic flags and operators.
As an anecdote, I guess the most complex thing I have done with Bash was scripting a deployment and starting test-runs onto a distributed system (and I think collecting results? I don’t remember). Bash was available and copying and starting processes via ssh was simple and robust enough. Notably, the scope and env requirements were very limited.
As one other comment mentioned, unfamiliarity with a particular language isn’t restricted to just bash. I could say the same for someone who only dabbles in C being made to read through Python. What’s this
@decoratorthing? Or what’sf"Some string: {variable}"supposed to do, and how’s memory being allocated here? It’s a domain, and we aren’t expected to know every single domain out there.And your mention of losing typing and structure information is… ehh… somewhat of a weird argument. There are many cases where you don’t care about the contents of an output and only care about the process of spitting out that output being a success or failure, and that’s bread and butter in shell scripts. Need to move some files, either locally or over a network, bash is good for most cases. If you do need something just a teeny bit more, like whether some key string or pattern exists in the output, there’s grep. Need to do basic string replacements? sed or awk. Of course, all that depends on how familiar you or your teammates are with each of those tools. If nearly half the team are not, stop using bash right there and write it in something else the team’s familiar with, no questions there.
This is somewhat of an aside, but jq is actually pretty well-known and rather heavily relied upon at this point. Not to the point of say sqlite, but definitely more than, say, grep alternatives like ripgrep. I’ve seen it used quite often in deployment scripts, especially when interfaced with some system that replies with a json output, which seems like an increasingly common data format that’s available in shell scripting.
Yes, every unfamiliar language requires some learning. But I don’t think the bash syntax is particularly approachable.
I searched and picked the first result, but this seems to present what I mean pretty well https://unix.stackexchange.com/questions/248164/bash-if-syntax-confusion which doesn’t even include the alternative if parens https://stackoverflow.com/questions/12765340/difference-between-parentheses-and-brackets-in-bash-conditionals
I find other languages syntaxes much more approachable.
I also mentioned the magic variable expansion operators. https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
Most other languages are more expressive.
You seem to be familiar with Bash syntax. But others may not be.
If by this you mean that the Bash syntax for doing certain things is horrible and that it could be expressed more clearly in something else, then yes, I agree, otherwise I’m not sure this is a problem on the same level as others.
OP could pick any language and have the same problem. Except maybe Python, but even that strays into symbolic line noise once a project gets big enough.
Either way, comments can be helpful when strange constructs are used. There are comments in my own Bash scripts that say what a line is doing rather than just why precisely because of this.
But I think the main issue with Bash (and maybe other shells), is that it’s parsed and run line by line. There’s nothing like a full script syntax check before the script is run, which most other languages provide as a bare minimum.
At the level you’re describing it’s fine. Preferably use shellcheck and
set -euo pipefailto make it more normal.But once I have any of:
- nested control structures, or
- multiple functions, or
- have to think about handling anything else than simple strings that other programs manipulate (including thinking about bash arrays or IFS), or
- bash scoping,
- producing my own formatted logs at different log levels,
I’m on to Python or something else. It’s better to get off bash before you have to juggle complexity in it.
-e is great until there’s a command that you want to allow to fail in some scenario.
I know OP is talking about bash specifically but pipefail isn’t portable and I’m not always on a system with bash installed.
-e is great until there’s a command that you want to allow to fail in some scenario.
Yeah, I sometimes do
set +e do_stuff set -eIt’s sort of the bash equivalent of a
try { do_stuff() } catch { /* intentionally bare catch for any exception and error */ /* usually a noop, but you could try some stuff with if and $? */ }I know OP is talking about bash specifically but pipefail isn’t portable and I’m not always on a system with bash installed.
Yeah, I’m happy I don’t really have to deal with that. My worst-case is having to ship to some developer machines running macos which has bash from the stone ages, but I can still do stuff like rely on
[[rather than have to deal with[. I don’t have a particular fondness for usingbashas anything but a sort of config file (withexport SETTING1=...etc) and some light handling of other applications, but I have even less fondness for POSIXsh. At that point I’m liable to rewrite it in Python, or if that’s not availaible in a user-friendly manner either, build a small static binary.It’s nice to agree with someone on the Internet for once :)
Have a great day!
Set don’t forget set -E as well to exit on failed subshells.
If you’re writing a lot of shell scripts and checking them with Shellcheck, and you’re still convinced that it’s totally safe… I tip my hat to you.
We are not taking about use of Bash in dev vs use Bash in production. This imho incorrect question that skirts around real problem in software development. We talk about use of Bash for simple enough tasks where code 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, data structures support, unit tests, 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
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’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
Can I slap a decorator on a Bash function? I love my
(viatenacity, even if it’s a bit wordy).
