Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)M
Posts
6
Comments
1083
Joined
3 yr. ago

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

  • Bash is for system maintenance, not for business logic.

    That is such a good guiding principle. I'm gonna borrow that.

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

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

  • Sure.

    I'll pick on postgres because 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.

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

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

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

  • Serious question (as a bash complainer):

    Have I missed an amazing bash library for secure database access that justifies a "perfectly good" here?

  • I actually (also) love bash, and use it like crazy.

    What I really hate is that bash is 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 invoke library 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".

  • 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 bash to 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 bash gathering 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.)

  • Heh. Maybe whoever they hire can fix it so that posts like this one (deep links to specific static content) appear without JavaScript enabled.

  • It's weird to realize I would wait in line for like 45 minutes up piss on Zuckerberg's grave, should the legal opportunity ever arise.

    Just a thought for his next of kin to consider, in due time...

  • I look forward to it (my own mortality) being a nice surprise.

    Hopefully a very long time from now.

    I'm the meantime, anyone want to buy my book on immortality? It has worked perfectly... So far.

  • Yeah. I like that their campaign slogan font is noticeably different than the previous deranged, delusional, maniac overlords. It's a refreshing change.

  • More or less. The man who appears in front of them is the narrator of "The Twilight Zone", who frequently appears to explain that the events of moments earlier are happening in an alternate, impossible, universe.

  • "Did you get the memo? There's a memo. I'll have someone bring you a copy, FOR THE GLORY OF THE EMPIRE!"

  • I don't think there's anything in the Fediverse meant to support the family updates use case.

    We use giant SMS text message threads for that.

    For more privacy, we get everyone to use Signal or XMPP with OMEMO.