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 (:
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?
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.