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-urlencoded request is super easy with curl. 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. curl already does all that.
  • Need to read from a curl response and it’s JSON? Reach for jq.
  • Instead of having to set up a connection object/instance to your database, give sqlite, psql, duckdb or 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 Ubuntu or debian or alpine, 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?

  • vext01@lemmy.sdf.org
    link
    fedilink
    arrow-up
    26
    ·
    6 days ago

    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.

  • melezhik@programming.dev
    link
    fedilink
    arrow-up
    14
    ·
    edit-2
    6 days ago

    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.

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      6
      ·
      6 days ago

      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.

        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          2
          ·
          5 days ago

          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.

      • melezhik@programming.dev
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        5 days ago

        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 …

  • ShawiniganHandshake@sh.itjust.works
    link
    fedilink
    arrow-up
    23
    ·
    7 days ago

    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.

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      5
      ·
      6 days ago

      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.

  • zygo_histo_morpheus@programming.dev
    link
    fedilink
    arrow-up
    18
    ·
    6 days ago

    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)

    • esa@discuss.tchncs.de
      link
      fedilink
      arrow-up
      7
      ·
      6 days ago

      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] = …
      
      • lurklurk@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        5 days ago

        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

        • esa@discuss.tchncs.de
          link
          fedilink
          arrow-up
          2
          ·
          5 days ago

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

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      3
      ·
      6 days ago

      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.

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    26
    arrow-down
    2
    ·
    7 days ago

    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:

    1. 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.
    2. Error handling. Sure you can set -e, but then that breaks pipelines and conditionals, and you end up with really monstrous pipelines full of pipefail noise. It’s also extremely easy to forget set -e.
    3. General robustness. Bash silently does the wrong thing a lot.

    instead of a import os; os.args[1] in Python, you just do $1

    No. If it’s missing $1 will 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.

    • JamonBear@sh.itjust.works
      link
      fedilink
      arrow-up
      6
      ·
      6 days ago

      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/sh ends up spawning an interactive shell…

      So you can add up binaries insanity on top of bash’s mess.

      • esa@discuss.tchncs.de
        link
        fedilink
        arrow-up
        2
        ·
        5 days ago

        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/sh ends up spawning an interactive shell…

        This runs into a part of the unix philosophy about doing one thing and doing it well: Extending programs to have more (absolutely useful) functionality winds up becoming a security risk. The shell is generally geared towards being a collection of shortcuts rather than a normal, predictable but tedious API.

        For a script like that you’d generally want to validate that the input is actually what you expect if it needs to handle hostile users, though. It’ll likely help the sleepy users too.

      • lurklurk@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        5 days ago

        I imagine adding -- so it becomes tar -caf archive.tar.bz2 -- "$@" would fix that specific case

        But yeah, putting bash in a position where it has more rights than the user providing the input is a really bad idea

      • MonkderVierte@lemmy.ml
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        6 days ago

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

    • lurklurk@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      5 days ago

      I don’t disagree with your point, but how does set -e break conditionals? I use it all the time without issues

      Pipefail I don’t use as much so perhaps that’s the issue?

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        5 days ago

        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-code or grep.

        I think I was actually thinking of pipefail though. If you don’t set it then errors in pipelines are ignored, which is obviously bad. If you do then you can’t use grep in pipelines.

        • lurklurk@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          5 days ago

          My sweet spot is set -ue because I like to be able to use things like if grep -q ...; then and 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

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      2
      ·
      6 days ago

      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 shellcheck and bash-language-server that 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 $1 will 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 -u to 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.

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        6 days ago

        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:

        1. “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.
        2. 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.
        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          arrow-down
          4
          ·
          6 days ago

          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.

          • FizzyOrange@programming.dev
            link
            fedilink
            arrow-up
            3
            arrow-down
            1
            ·
            5 days ago

            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?

  • flatbield@beehaw.org
    link
    fedilink
    English
    arrow-up
    9
    ·
    6 days ago

    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.

      • flatbield@beehaw.org
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        6 days ago

        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.

        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          ·
          5 days ago

          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?

          • flatbield@beehaw.org
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            5 days ago

            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.

          • flatbield@beehaw.org
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            5 days ago

            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.

  • esa@discuss.tchncs.de
    link
    fedilink
    arrow-up
    13
    ·
    7 days ago

    At the level you’re describing it’s fine. Preferably use shellcheck and set -euo pipefail to 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.

    • vext01@lemmy.sdf.org
      link
      fedilink
      arrow-up
      2
      ·
      6 days ago

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

      • esa@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        6 days ago

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

        It’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 using bash as anything but a sort of config file (with export SETTING1=... etc) and some light handling of other applications, but I have even less fondness for POSIX sh. 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.

  • toynbee@lemmy.world
    link
    fedilink
    arrow-up
    9
    ·
    7 days ago

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

  • Ephera@lemmy.ml
    link
    fedilink
    English
    arrow-up
    7
    ·
    7 days ago

    Wanna check if a variable’s set to something expected? if [[ <test goes here> ]]; then <handle>; fi

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

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      4
      ·
      7 days ago

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

      That said, man test is my friend.

      But I’ve also gotten so used to using it that I remember -z and -n by heart :P

      • calcopiritus@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        6 days ago

        If 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 -z and -n every 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 of syd, os or path.

        The first time I want to do an else if my IDE will mark it red and I’ll write eliffrom 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.

        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          ·
          6 days ago

          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 I mkdir -p? What about cp or mv and 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-server that can warn you of some syntactical errors.

  • synae[he/him]@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    6 days ago

    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…

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      2
      ·
      6 days ago

      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.

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    7
    ·
    7 days ago

    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.

    • palordrolap@fedia.io
      link
      fedilink
      arrow-up
      8
      ·
      7 days ago

      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.

      • Kissaki@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 days ago

        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.

        Personally, I don’t see python far off from bash. Decent for small scripts, bad for anything bigger. While not necessarily natively available, it’s readily available and more portable (Windows), and has a rich library ecosystem.

        Personally, I dislike the indent syntax. And the various tooling and complexities don’t feel approachable or stable, and structuring not good.

        But maybe that’s me. Many people seem to enjoy or reach for python even for complex systems.

        More structured and stable programming languages do not have these issues.

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      2
      ·
      7 days ago

      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 @decorator thing? Or what’s f"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.

      • Kissaki@programming.dev
        link
        fedilink
        English
        arrow-up
        5
        ·
        6 days ago

        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.

        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          ·
          6 days ago

          Your experiences are based on your familiarity with other languages. It may or may not apply to others. So to each their own I guess?

          I do agree that the square bracket situation is not best though. But once you know it, you, well, know it. There’s also shellcheck to warn you of gotchas. Not the best to write in, but we have linters in most modern languages for a reason.

          I actually like bash’s variable expansion. It’s very succinct (so easier to write and move onto your next thing) and handles many common cases. The handling is what I hope most stdlibs in languages would do with env vars by default, instead of having to write a whole function to do that handling. Falling back is very very commonly used in my experience.

          There are cases where programming is an exercise of building something. Other times, it’s a language, and when we speak, we don’t necessarily want to think too much about syntax or grammar, and we’d even invent syntaxes to make what we have to say shorter and easier to say, so that we may speak at the speed of thought.

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      6 days ago

      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)

      • ZeroOne@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        6 days ago

        Basically, If you are crazy enough, you csn make anything with any language<br> Hence, me sharing the video

  • MonkderVierte@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    6 days ago

    Run checkbashisms over your $PATH (grep for #!/bin/sh). That’s the problem with Bash.
    #!/bin/sh is for POSIX compliant shell scripts only, use #!/bin/bash if you use bash syntax.

    Btw, i quite like yash.

      • MonkderVierte@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        6 days ago

        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.

        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          ·
          6 days ago

          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 /bin like you said, and some would much prefer that you use the first bash that appears in their PATH, e.g. in nix.

          But yeah, it’s generally pretty safe to assume /bin/sh will 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.

          • MonkderVierte@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            6 days ago

            Not all systems have bash being accessible at /bin like you say

            Yeah, 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-sh in AUR, a pacman hook that symlinks. Nothing important breaks by doing so.

            • FooBarrington@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              5 days ago

              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?

  • locuester@lemmy.zip
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    4 days ago

    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.

    • FizzyOrange@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      3 days ago

      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.

    • Badland9085@lemm.eeOP
      link
      fedilink
      arrow-up
      1
      ·
      4 days ago

      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.

      • locuester@lemmy.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 days ago

        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.

        • Badland9085@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          ·
          4 days ago

          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!

          • locuester@lemmy.zip
            link
            fedilink
            English
            arrow-up
            3
            ·
            4 days ago

            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.