3 ms·

I like the idea, but I think I'd prefer to go more towards mdsh - I already write up markdown documents for various tasks - I would prefer extracting and runnin

by e12e 6y ago

I like the idea, but I think I'd prefer to go more towards mdsh - I already write up markdown documents for various tasks - I would prefer extracting and running code directly from file (eg: a local checkout of a gitlab wiki project, or from a docs-folder in a checkout of a regular project). Maybe I can bend mdsh to my needs with a bit of inspiration from your project. Currently there's expected to be a bit of copy paste from the wiki/rendered markdown - but that only scales so far. (I generally do drop helper scripts in a project /bin folder, and document the use of those via markdown - but having a sensible way to execute code blocks would maybe help). Ed: Or perhaps I'm better off just using https://zyedidia.github.io/literate/index.html https://zyedidia.github.io/literate/index.html directly.

thaumaturgy 6y ago
I started with "just use mdsh", but then found that executing mdsh scripts on remote servers was yucky; either the file needed to be copied up, executed, and then cleaned up, or the file was executed over ssh but that was fragile. It took a lot of tries to find a way to do it that didn't break bash or sudo or interactive prompts from remote programs. I used that trick for a while, but it required the `--compile` option for mdsh, and re-compiling each script every time was silly. Also, I wanted shellcheck to look at the output each time to make sure something wasn't horribly broken before running some markdown on a server. (Other than the part where I'm running markdown on a remote server.) So, I started caching the compiled files. Then I wanted a couple of convenience functions added to them. Then golem sort of happened. It pretty much just takes mdsh and makes it safer and nicer to run on remotes.
- e12e 6y ago
  Right. My use case is more to tweak and test a few scripts, then have a(nother| junior) dev(op) be able to clone a repo and set up a service or server. Maybe with some minor obvious tweaks. I've looked at ansible - but I'm not convinced that it's a good fit; ansible feels a bit like a padded straight jacket, rather than comfortable outwear, so to speak. I need to weaponize my documentation, rather than dull the edge of my shell recepies ;)

by e12e 6y ago

thaumaturgy 6y ago

I started with "just use mdsh", but then found that executing mdsh scripts on remote servers was yucky; either the file needed to be copied up, executed, and then cleaned up, or the file was executed over ssh but that was fragile. It took a lot of tries to find a way to do it that didn't break bash or sudo or interactive prompts from remote programs. I used that trick for a while, but it required the `--compile` option for mdsh, and re-compiling each script every time was silly. Also, I wanted shellcheck to look at the output each time to make sure something wasn't horribly broken before running some markdown on a server. (Other than the part where I'm running markdown on a remote server.) So, I started caching the compiled files. Then I wanted a couple of convenience functions added to them. Then golem sort of happened. It pretty much just takes mdsh and makes it safer and nicer to run on remotes.

e12e 6y ago
Right. My use case is more to tweak and test a few scripts, then have a(nother| junior) dev(op) be able to clone a repo and set up a service or server. Maybe with some minor obvious tweaks. I've looked at ansible - but I'm not convinced that it's a good fit; ansible feels a bit like a padded straight jacket, rather than comfortable outwear, so to speak. I need to weaponize my documentation, rather than dull the edge of my shell recepies ;)