1. 18
  1. 30

    Unpopular opinion: I use bash all the way up til I need more than associative arrays, then I use Rust. It works surprisingly well for scripting tasks.

    1. 15

      Other than the rust part, I suggest this is the popular opinion ;-)

      1. 7

        Julialang.org is especially good. But I need to google how to use it all the time.

        And JS in contrast is my “native” language. I remember it even at night at 3 a.m. So scripting in JS is much easier for me let’s say than in bash.

        But something is just easier in bash, like cat | wc -l. Zx helps me to combine the power of the two.

        I also believe it’s true for lots of people. This is why zx saw such an increase in popularity.

        1. 4

          You’re absolutely right. That’s why it’s an unpopular opinion. 😁

          I’m fully aware that I’m far more willing to write far more bash (and zsh) than most people.

          1. 1

            Julia is tough for me as well, so much feels very magical and I don’t really know how to operate it.. but when it works it’s very cool

          2. 3

            Ditto, but I reach for Ruby because other folks in my team/servers have the runtime installed.

            1. 3

              For scripting inside a project I tend to include an executable task file with this Python starter: https://gist.github.com/sirikon/d4327b6cc3de5cc244dbe5529d8f53ae

              1. 1

                What is the advantage of this as opposed to just write whatever code you need directly and run the script?

                1. 1

                  With the Python starter I get the basic, repeating stuff done:

                  • A simple help command is generated (triggered by running just ./task), after a week or so without touching a project I just forget the commands and want a quick help.
                  • Working directory switched to the task file’s directory, handy when running the script from another place like a subdirectory.
                  • A cmd function as a pass-thru to subprocess.run, but forcing check=True.

                  Here’s the task file from one of my projects, as an example: https://github.com/sirikon/bilbostack-app/blob/master/task

              2. 2

                /bin/sh to perl for me. I’d rather try (un)icon and scsh than javascript.

                1. 2

                  I usually use Python since it’s available, though I entirely understand your sentiment due to the built-in std::process and clap crate.

                  1. 5

                    the moment I need more than bash I just look which lang is available and has the right libraries, can be rust, can be python..

                    1. 1

                      Have you tried xonsh?

                  2. 5

                    Shameless promo: zxpy.

                    I made it because I immediately didn’t like the syntax and the choice of language, and thought I can do better. It suits my usecases nicely.

                    1. 3

                      I love the idea of zx, but the sad reality of having to install the runtime for the scripts puts me off completely.

                      1. 3

                        I wrote a thin wrapper around DukTape a few years ago for experimenting with C FFI. It ended up as a binary that was < 1 MiB with no dependencies other than libc (and pthreads, for web workers). I wonder how difficult it would be to run zx in this kind of environment. If your script interpreter is a single binary that’s smaller than bash, then it seems quite plausible as a dependency - even if it isn’t in your base system, it’s easy to add to package repos and VM / container images.

                        I’m quite tempted to try this with jsquick, which has a nice mode for compiling JavaScript to bytecode that can then be bundled with the binary. If jsquick can run zx, then you could provide a single small binary for zx without a Node.js dependency.

                        1. 1

                          That sounds like the right way to go about it. For most Go projects I’ve settled for using task that - while not as powerful as zx - builds to a single binary I can just download into my build/dev environment with a single command.

                          I guess zx would work just fine for people who already have a JS/TS project and just need to add the extra packages to the environment they’ve already setup, but for everyone else it sounds like a hassle.

                          1. 1

                            Oh, this makes me think – FreeBSD has flua in base, so a lua “zx” might be super useful…

                        2. 2

                          FWIW you can do this in perl without any libraries (and may be inspiration for the name of this, IDK):

                          my $branch = `git branch --show-current`;
                          my $deploy = qx{dep deploy --branch=$branch};   # qx{} is equivalent to wrapping in backticks
                          1. 2

                            oh and also built-in heredocs

                            my $markdown =<<"EOF";
                            # Fruits
                            Favorites are:
                            - apple
                            - pear
                            - banana
                            1. 1

                              What about escaping arguments? Zx will quota an arg inside ${}

                              1. 1

                                I suspect that it will. For example the related qq[This isn't a test] double quote operator does escaping

                                If you have a specific example I’m happy to give it a try

                            2. 2

                              Just image, zx plus something like this: https://github.com/kellyjonbrazil/jc and you could get typescript types for bash commands.

                              Pair it with something like Nix to ensure that you’re using a version of the executable that matches the expected output format and you’d be off to the races.

                              I agree with @peter that I mostly just write bash-style scripts in higher-level languages these days, but I wonder if zx plus good editor tooling and typescript type hints would be a very productive combo.

                              1. 1

                                One of the things that are convenient with Bash and zsh is that the script that worked 5-10 years ago will most probably work without a hitch now (with possible need to get all dependent tools).

                                What is the situation with zx? How future proof one expects it to be, would it easily work with a future nodejs? I’m asking this because there was a recent discussion how people had issues getting old nodejs projects to run.

                                And before someone mentions nix for dependencies, what are your experiences with starting an old version of a nix project, for example something that has not been touched since 2018?

                                1. 2

                                  Despite the major version incrementing yearly, breaking changes for userland code in nodejs are quite rare in my experience. The pain of running old nodejs projects is usually due to the authors of the project not being specific enough in defining what versions of their dependencies should be installed.

                                2. 1

                                  Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice, but standard Node.js library requires additional hassle before using. The zx package provides useful wrappers around child_process, escapes arguments and gives sensible defaults.

                                  1. 8

                                    JavaScript is a perfect choice

                                    Is it that common for javascript to be installed on servers and workstations?

                                    When I reach the limits of palatable shell scripting, I typically reach for python or Go or something like that.

                                    1. 4

                                      Nope, it’s not common at all. But, when they say “JavaScript is a perfect choice”, I don’t think they’re claiming it’s perfect because a JavaScript interpreter is installed everywhere. I think they’re saying it’s perfect because they find merit in the syntax/semantics of JavaScript and, consequently, its suitability for addressing problems that are typically solved by scripting

                                      In the same vein as what you mention, though, I think the question is whether the value-add of using a language like this outweighs the convenience of being able to hand off a script to someone else so that they can run it on a different machine without additional dependencies. As zx does not ship, by default, in many OS distributions (unlike sh and bash), it’s unlikely that handing a zx script to someone else to run on a different machine would work. For that reason, I think they will struggle with adoption.

                                      That said, I do think it’s far more enticing to use a new scripting language if there is a translation layer (which zx might have, I haven’t looked very hard) to and from a prevalent scripting language like sh or bash.

                                      It’s one of the things that I like about the Oil project (plug @andyc). From their Wiki:

                                      You can gracefully upgrade your shell scripts to it [Oil], or write brand new scripts in it.

                                      1. 2

                                        Is it that common for javascript to be installed on servers and workstations?

                                        If you do webdev, yes

                                        1. 1

                                          You’ll also find jsc on every Mac and any system with WebKitGTK installed (upd: unless the distro cuts it out or packages it separately), but it won’t be useful for any scripts that have to touch the system in any way. Also gjs on any desktop with a substantial amount of GNOME apps, and that is far more useful, but practically nobody uses it for non-GUI apps.

                                        2. 1

                                          All fronted folks have it.