Show HN: Run – Easily manage and invoke small scripts and wrappers | Hacker News Reader

Show HN: Run – Easily manage and invoke small scripts and wrappers

github.com

107 pointsTekWizely26 comments

I recently looked at many task runners. I settled on my own personal task runner only because of familiarity. I would switch to either of these if I wasn't so heavily invested in my own tool.

[just](https://github.com/casey/just) [task](https://github.com/go-task/task)

I'm not sure what Run does that the two above don't.

I personally find Run to be the easiest of the three to understand (it's self-documenting like a Dockerfile) and get started with, and I have exp with none of them.

Hi @mmgutz,

Thanks for linking these other projects - I'm going to add a section in my README linking to other projects that people might find useful for their various use cases.

Go-task feels like a build tool and not really a general task runner.

Looks like Just brings a lot of similar features and I will definitely be looking into it deeper. However it still touts itself a build-tool at heart.

Run is NOT trying to be a build tool - It wants to be a script/wrapper manager and so the feature set is trying to optimize for that.

Thanks for the question - I hope that helps - Please let me know if you have any other questions or comments.

BTW: Can you link to your "own personal task runner" ? I'd love to see it and others might find it useful, too.

HN is known for snark so I should say I'm genuinely not trying to be snarky. I don't understand why I would use this over a Makefile. The biggest difference is that "run" autogenerates nice help output?

To my understanding, a Makefile is designed for single commands and not for scripts.

Hi @brian_cloutier,

A couple of things that come to mind (although I should probably flesh out a section on the README for this):

* Auto-Generated Help From comments - There are patterns for adding a 'help' target in make that generates light documentation for the targets - I maintain a gist for such a pattern in a different github account.

* Per-Command Shell - bash, python, ruby, you decide !

* Per-Command Options/flags - With documentation!

* Positional Arguments - By default, make treats all non-variable arguments as targets, so you can't say "make action argument"

* Commands Executed in One Sub-Shell - By default make executes each line of a recipe in a separate sub-shell, requiring you to use '\' to link multiple lines into a single recipe.

No doubt make is useful for this, hence why all my dev friends use it, but make was not designed to manage non-build-related targets, and has some cracks in it with regards to that use case.

I think (hope) run can prove useful as a dedicated tool for this use case.

Thanks for the question - I hope that helps - Please let me know if you have any other comments or questions.

Thanks for the response, this is a solid list!

Thanks for that list as well!

Would you be so kind to also answer the question why one would use it over pure bash scripts?

Hi @kariert,

I think a first answer could be answering with a question:

"Why do so many people use makefiles to just manage tasks/scripts/wrappers instead of using pure bash scripts"

One reason may be that they are already using make in their project for actual build targets, but I see many pure task-only makefiles out there, so its not the only reason.

I think another reason is ease of use - The syntax is very terse and you can get a useful task runner with just a few lines of text.

With regards to Run, one of the additional features it brings is the ability for your 'commands' to be any type of script and not just bash.

You could have small scripts coded ruby, python, perl, etc all mixed together and managed within a single Runfile.

Thanks for the question - I hope that helps - Please let me know if you have any further comments or questions.

Having gone through writing a couple of iterations of these, I went back to settling on `PATH="./scripts/:$PATH"`, which in my project root dirs (where I spend 99% of my time anyway on the shell) just works.

Sure, this could be augmented with per-folder environments, fancy runner syntax, but less is more for me in this regard.

Ninja update: Anyway, I like what OP is doing here, seems like a lot of things are done right in this. :)

reminds me of https://github.com/tj/robo.

Great job on releasing this. I was just thinking about all the scripts in my makefile. Separation of concerns. I’ll be giving it a try.

I must admit robo is clever for using YAML where I built an entire parser to do somewhat the same thing :)

In your defence, Robo doesn't appear to handle arguments or let you write single-file scripts, at best you can make it run an external script.

This would be an interesting alternative to travis-ci or appveyor scripts (where you are locked in to that tech). By using this you can have scripts that run local or run on CI, and just have a one liner on travis-ci to call Run.

I was thinking the same thing, as I just had to create a bunch of ci scripts to preload a Firestore db and cloud functions for a pipeline using a gcloud emulator.

This is a great project, and I will be using it to both replace old scripts and make new ones.

Also, if you give me a week (I might be able to do it today or tomorrow tho), I'll submit a PR for an Archlinux PKGBUILD.

Greetings!

Yeah I haven't done much with Package managers (PKGBUILD, brew, etc) and thinking this project might be my excuse to start learning them.

Thanks for your kind words and offer for a PR - I'll keep an eye out for it !

Here it is: https://github.com/TekWizely/run/pull/2

That was a very short week!

This looks pretty nice, and I like the idea of a universal help/getopts syntax that can work over different execution engines (python, bash, etc.)

I just did a new install at home, and may try reimplementing some of my utility scripts in terms of this just to see how it plays.

How does run compare with expect[1]?

1: http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.htm...

Greetings!

I would say that expect is quite a different beast entirely. I think of expect more as an interactive scripting language. Something you might use in place of bash to write a small script that requires user interaction.

Run is more of the tool you might use to organize your expect / bash / etc. scripts and easily invoke them.

Pretty much every dev I know has used makefiles as a means to organize small, non-build-related, scripts and shell wrappers. Run hopes to be a better tool for doing that.

Thanks for the question - I hope that helped - Please let me know if you have any other questions or comments.

Expect is designed for an entirely different use case, it can "talk" to other interactive programs following a script. Run is intended to act as a replacement for using Makefiles as scripts (and is super awesome at that too). Basically, you'd find yourself using Expect inside a Runfile.

Good work.

I have done something similar by creating bash functions in a file then sourcing that, making them available as and when I want.

This looks nice though.

Nice work, TekWizely! This looks looks like a well thought out little tool with a good niche.

Thanks @a_band - Please don't hesitate to submit a bug report (or feature request!) if you get a chance to play around with it.

Reply on news.ycombinator.com