4 ms·

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

107 points by TekWizely 7y ago

blacksmith_tb 7y ago
How does run compare with expect[1]? 1: http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.html http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.htm...
- deleted 7y ago
  [deleted]
- TekWizely 7y ago
  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.
- chabad360 7y ago
  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.
cgarvis 7y ago
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 7y ago
  I must admit robo is clever for using YAML where I built an entire parser to do somewhat the same thing :)
  - chabad360 7y ago
    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.
chabad360 7y ago
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 7y ago
  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 7y ago
    Here it is: https://github.com/TekWizely/run/pull/2 https://github.com/TekWizely/run/pull/2
    - Moghammed 7y ago
      That was a very short week!
a_band 7y ago
Nice work, TekWizely! This looks looks like a well thought out little tool with a good niche.
- TekWizely 7y ago
  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.
brian_cloutier 7y ago
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?
- chabad360 7y ago
  To my understanding, a Makefile is designed for single commands and not for scripts.
- TekWizely 7y ago
  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.
  - brian_cloutier 7y ago
    Thanks for the response, this is a solid list!
  - kariert 7y ago
    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?
mmgutz 7y ago
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.
- chabad360 7y ago
  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.
- TekWizely 7y ago
  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.
mc3 7y ago
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 7y ago
  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.
bastih 7y ago
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. :)
kitd 7y ago
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.
geoelectric 7y ago
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.

107 points by TekWizely 7y ago

How does run compare with expect[1]? 1: http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.html http://manpages.ubuntu.com/manpages/bionic/man1/expect.1.htm...

deleted 7y ago
[deleted]
TekWizely 7y ago
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.
chabad360 7y ago
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.

cgarvis 7y ago

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 7y ago
I must admit robo is clever for using YAML where I built an entire parser to do somewhat the same thing :)
- chabad360 7y ago
  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.

chabad360 7y ago

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 7y ago
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 7y ago
  Here it is: https://github.com/TekWizely/run/pull/2 https://github.com/TekWizely/run/pull/2
  - Moghammed 7y ago
    That was a very short week!

a_band 7y ago

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

TekWizely 7y ago
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.

brian_cloutier 7y ago

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?

chabad360 7y ago
To my understanding, a Makefile is designed for single commands and not for scripts.
TekWizely 7y ago
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.
- brian_cloutier 7y ago
  Thanks for the response, this is a solid list!
- kariert 7y ago
  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?

mmgutz 7y ago

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.

chabad360 7y ago
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.
TekWizely 7y ago
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.

mc3 7y ago

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 7y ago
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.

bastih 7y ago

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

kitd 7y ago

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.

geoelectric 7y ago

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.