Show HN: Shmux – run all your scripts from one file(github.com)
github.com
Show HN: Shmux – run all your scripts from one file
https://github.com/shikaan/shmux
9 comments
Recommend https://just.systems/man/en/ for a mature and more capable version of this.
I also like https://github.com/go-task/task
[deleted]
Took a quick look at the GitHub page. You should explain what this does.
Seemed fairly obvious to me just skimming.
I actually really like the idea. Makefiles always seemed a bit wrong to use for utility scripts, and a folder of sh files also seemed a bit excessive to me.
The makefile sections + argument injection is very clever. I hate looking up how to parse argv in different languages all the time for simple tasks.
I have just a few nit-picks that would stop me from picking it over a directory of scripts, however.
1. It would be yet another dependency to worry about. Maybe instead of it's own executable, it could be a script you add to your repo like how java's gradle works (maybe just an executable sh file called "shmux"?)
2. I'm not a fan of relying on environment variables for it to work. It's just clunky and I know I'd have to look up what to put in if I switch between projects a lot. Perhaps consider letting this "shmux" executable look for a "shmux.*" glob, then run the first one it finds. Then let a #! define what language to use.
Just speaking to my own workflows and tooling expectations, you're definitely getting there for something I would personally use on my hobby projects.
I actually really like the idea. Makefiles always seemed a bit wrong to use for utility scripts, and a folder of sh files also seemed a bit excessive to me.
The makefile sections + argument injection is very clever. I hate looking up how to parse argv in different languages all the time for simple tasks.
I have just a few nit-picks that would stop me from picking it over a directory of scripts, however.
1. It would be yet another dependency to worry about. Maybe instead of it's own executable, it could be a script you add to your repo like how java's gradle works (maybe just an executable sh file called "shmux"?)
2. I'm not a fan of relying on environment variables for it to work. It's just clunky and I know I'd have to look up what to put in if I switch between projects a lot. Perhaps consider letting this "shmux" executable look for a "shmux.*" glob, then run the first one it finds. Then let a #! define what language to use.
Just speaking to my own workflows and tooling expectations, you're definitely getting there for something I would personally use on my hobby projects.
Hi! Thanks a lot for this comment (: The sentiment you share is exactly where I was coming from when I was working on it.
Huge thanks also for the suggestions, especially #2 seem to make a lot of sense. I thought about using #!, but having sensible defaults for shmuxfiles is very smart too.
I'll keep this thread posted if I get to work in it reasonably soon. Thanks again (:
Huge thanks also for the suggestions, especially #2 seem to make a lot of sense. I thought about using #!, but having sensible defaults for shmuxfiles is very smart too.
I'll keep this thread posted if I get to work in it reasonably soon. Thanks again (:
Hey! Thanks for the feedback (: There's a "quick start" section with usage, which I hoped was addressing this. Is there anything specific you would like to see?
The main problem with nice tools like this is the bootstrap problem: unless something is already on every teammate machine or unless something is so obviously essential that people will go through the extra hassle of installing it (and making sure you have an up to date version of the tool!), you'll always have the incentive to make it do with something simpler or piggyback to something you already use (your build system, make, shell scripts, etc).
When I read the title here, I though this project was about multiplexing multiple shell scripts inside a single shell script, literally without a "runner" you have to install.
I wonder how would that look like
When I read the title here, I though this project was about multiplexing multiple shell scripts inside a single shell script, literally without a "runner" you have to install.
I wonder how would that look like
It's rough, but it might be useful for somebody. Any type of feedback is welcome!