1. 5
  1.  

  2. 1

    Yet another program that re-implements shell scrips.

    If I were to use one of these kinds of tools I’d probably use Just, but I’ve never seen a reason to.

    1. 3

      On the contrary, z-run, just like just (which I’ve looked at) don’t “re-implement shell scripts”, instead they build upon shell scripts and cover some corner use cases that shell scripting doesn’t solve easily. For example:

      • (in case of just) it is dependencies between shell scripts;

      • (both z-run and just) its easily mixing multiple scripting languages inside the same source file; (you can get this with here-documents in plain shell but it doesn’t work for complex pipelines nor does it play nicely when you also need stdin;)

      • (both z-run and just) modularity – it’s quite hard to implement modular shell scripts; functions and sourcing are two solutions, but given the shell’s dynamic scoping when it comes to (environment) variables (unless one uses local) you quickly get into trouble; (also some “sanity” flags like set -e don’t apply to functions automatically;) thus my own pattern is having one large script file with case "${command}" in ( name-that-otherwise-would-be-a-function-name ) ... ;; esac, and instead of calling functions I call "${0}" some-sub-command ..., which makes sure the “function” doesn’t taint the environment of the calling script;

      • (in case of z-run) remote execution via SSH – just the simple ssh user@host rm '/some path that might contain a space' breaks due to the lack of extra quoting;

      • (in case of z-run and make) dynamic generation of scripts (both as code and as source); in shell we might have source <( some command ), but at least with z-run it’s easier, and the some command output is cached;

      Than being said, I’m a long time Linux user, writing a lot of shell scripts (bash) both personally and professionally; thus z-run is not something I’ve came up in my first year of using Linux. For a long time I’ve actually used shell scripts like these ones where I’ve tried to modularize them; however that is much more tedious than using z-run, at least for development and operations.

    2. 1

      I just wanted to make a small comparison with just: although the readme says it’s not a build system, I consider it closer to make than a general-purpose “command runner”.

      So while both z-run and just provide a way to write small code snippets in the same file and then easily execute them, I would say z-run set’s apart from just by being more generic:

      • just has recipes that can depend upon each-other, and multiple recipes can be invoked in the same CLI invocation; on the other hand z-run doesn’t have support for this, it basically provides a vay to just call another “scriptlet” (as I call them), and it’s the job of the developer to properly chain dependencies (and detect if they need to be executed or not); (just see how positional arguments are handled in just and you can see they are a special case in just;)

      • just has defined a kind of template language that preprocesses the recipe body, especially for argument replacement; z-run doesn’t touch the body of the scriptlet; (on the other hand z-run does support templating, one example is the built-in Go text/template based one, but it has to be explicitly called by the user;)

      • z-run has the built-in possibility of running scriptlets via ssh on a remote host (allowing those scriptlets to call other scriptlets, but also remotely;)

      • z-run has built-in support, and is optimized for, generating the scriptlet sources dymanically (especially for having a very explicit fzf-based menu of potential options);

      • z-run‘s UI (if one can call it like that) is by leveraging a fzf-based workflow: it presents you with all the options (possibly organized into menus), and you don’t need auto-completion; (here is where dynamic source generation comes into play: one writes generic scriptlets that accept various arguments, just like any other script, but then you take all the ways in which they can be called, which is usually a small list of options, and generate scriptlets that just call the generic one;)

      1. 1

        I think I’m going to try this. I’m helping out a scientist with some workflow automation.

        1. 1

          If you have any questions, just let me know and I’m open to help integrating / using it (free of charge, especially given it’s about science); you could:

          BTW, I already have used z-run with my own https://github.com/cipriancraciun/covid19-datasets “data science project”.

          1. 1

            Will do. Looking forward to giving it a shot.