
Show HN: Run – Easily manage and invoke small scripts and wrappers - TekWizely
https://github.com/TekWizely/run
======
mmgutz
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](https://github.com/casey/just))
[task]([https://github.com/go-task/task](https://github.com/go-task/task))

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

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

------
brian_cloutier
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?

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

~~~
kariert
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?

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

------
bastih
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. :)

------
cgarvis
reminds me of [https://github.com/tj/robo](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.

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

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

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

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

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

~~~
TekWizely
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 !

~~~
chabad360
Here it is:
[https://github.com/TekWizely/run/pull/2](https://github.com/TekWizely/run/pull/2)

~~~
Moghammed
That was a very short week!

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

------
blacksmith_tb
How does run compare with expect[1]?

1:
[http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.htm...](http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.html)

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

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

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

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

