Comment on What are the recommended scripting languages for complex shell scripts beyond bash?

Knusper@feddit.de ⁨10⁩ ⁨months⁩ ago

• beejjorgensen@lemmy.sdf.org ⁨10⁩ ⁨months⁩ ago

  A shell script can be more concise if you’re doing a lot of shell things. Keeps you from having os.system() all over the place.

  Things like “diff the output of two programs” are just more complex in other languages.

  I love rust, but replacing my shell scripts with rust is not something I would consider doing any more than I’d consider replacing rust with my shell scripts.

  source

  • Knusper@feddit.de ⁨10⁩ ⁨months⁩ ago

    Oh, I didn’t mean to say, you should throw out your shell scripts. For anything less than, say, 20 lines, they’re perfectly appropriate.

    I’m saying, Rust starts to feel like a good choice from, say, 100 lines upwards, and I just don’t think, it’s worth bridging the gap between those two.

    In particular, you can build a function that allows you to run commands without much boilerplate, e.g.: run(“echo hello | tee out.txt”);
    (The implementation just appends that argument to Command::new(“sh”).arg(“-c”) and runs it.)

    That way, you can do the more complex things in Rust, whether that’s control flow or something like modifying a JSON file, without giving up the utility of all the CLI tools on your system…

    source

    • Knusper@feddit.de ⁨10⁩ ⁨months⁩ ago

      Somewhat of a weird addendum, but I actually only realized, you could port directly over like that, while writing the above comment.

      Now I actually tried it on a 22 lines long shell script that I’ve been struggling with, and holy crap, I love it.

      Like, I should say that I have always been (and likely will always be) shit at shell scripting. Any time I wanted to do a basic if, I had to look up how that works.
      As a result, even those 22 lines were ripe with code duplication and I always felt really unsure about what will actually happen during execution.

      Well, rightfully so. While porting over, I realized I had a bug in there, which has been annoying me for a while, but I always thought, well, it is a shitty shell script. I still remember thinking, I should probably not implement it like that, but then leaving it anyways, because I felt it would become unreadable with the shell syntax.

      Now it actually feels maintainable, like I can even easily expand on it.
      And I have to say that rust-script is really smooth. I barely notice that it’s compiling during the first run after changing the script file, and it’s fully cached afterwards, so it executes instantly.

      I’ll still have to check for libraries that basically provide such a run() function/macro for me, but yeah, basically my threshold for not using shell scripts just dropped to any kind of control flow being involved.

      source

      • philm@programming.dev ⁨10⁩ ⁨months⁩ ago

        Yeah the strict type-system of Rust is great at finding issues.

        I think when understanding, that bash is basically only programs with parameters ([ is a program that takes all kinds of parameters and as last parameter ]) then bash is quite ok for stuff that doesn’t need a lot of algorithms, i.e. passing the in and out from one program to another. But as soon as there’s basic logic, You’ll want to use a fully-fledged programming language.

        Also the maintainability aspect: You can just start using fancy stuff you never want to use in bash and it can slowly grow into a library or application or something like that.

        Btw. I have started a syntax-sugar library/crate that creates typing information for all kinds of programs via the builder-type-state-pattern, so that you don’t always have to look up man etc. and that it should be more convenient to execute programs (not open sourced yet, and low priority for me as I’m working on various other exciting projects currently)

        source
• philm@programming.dev ⁨10⁩ ⁨months⁩ ago

  Yeah as weird as it sounds to use a “low”-level systems programming language such as Rust. Rust works surprisingly well as “script” language. (And you don’t have to deal with the ugliness of bash, admittedly though, that bash is quite a bit more concise when using a lot of program executions and piping the results etc.)

  source
• pathief@lemmy.world ⁨10⁩ ⁨months⁩ ago

  I make bash scripts to automate the configuration of new servers. Stuff like install packages, create users, create groups, configure the database, manage permissions…

  I feel like that sort of stuff would be a nightmare to do in high level languages but maybe I’m just too used to bash.

  source

  • Knusper@feddit.de ⁨10⁩ ⁨months⁩ ago

    As I already responded to others, my comment was meant in the context of the question, so I would not learn a scripting language in addition to Bash + a programming language.

    For just running commands one-after-another, Bash is basically a minimal encoding, so no reason not to use it.

    When you do start to need if-elses, loops etc., that’s where Bash starts to become somewhat difficult to read. And personally, as someone who’s not fluent in Bash control flow, I found it quite useful to do the control flow in my programming language of choice, but still just calling commands like you’d do in Bash.

    Of course, this is a non-standard setup, and most target hosts will have Bash pre-installed, not rust-script, so it does obviously make a lot of sense to continue using Bash for what you’re doing.
    In general, my comment was meant for programmers. An ops person might know a full-fledged programming language, but still want to learn Python, because they need to write tons of Ansible tasks or whatever.

    source