It would also be nice if it would show you all the steps beforehand, and then check each item as you progress. Sometimes it's good to actually prepare from a broader perspective.
And it could log into a file as a summary.
So much that could be improved, which is why the simplest solution might be the best.
You could do this with a nicer cli library, so you could show the checklist and running output of each stage, which would be nice regardless of what steps are automated.
My main issue with that is that a do nothing shell script is so easy to get started with that it's hard not to complete it, and your efforts may be better used automating one of the steps. You may get lost in a fun but not that productive quagmire of which TUI library and how to structure everything.
I'm glad this is mentioned! This is why instead of a Bash script, I use a Makefile. Each step is a rule with a *.done name, that generates a .done file once it's done. I can interrupt it any time, modify the script to fix something, and `make` to resume.
But writing that Makefile is a PITA. Is there a better solution?
I’ve just switched to using just https://github.com/casey/just for my makefiles that were really just a collection of small snippets and it’s worked wonderfully
When I do this I keep some persistent state so I can interrupt it, e.g. if the thing is a yearly task I run it like `./do-the-thing.sh 2025`, and make a 2025 dir where I keep state on how far I've gotten
So if you OK the first step, I can touch a 2025/first-step file. If the script crashes or is interrupted and rerun, it can check for that file and skip the first step
If something has changed so the automation doesn't work, it's nice to be able to crash out without losing state, fix the script and rerun.
I usually have the script tell me just the next manual step and then exit, because that frees the terminal up for me to do other things. I can use the command history to rerun the script easily
I think the simplest solution would be to just do what the article says and not do all that extra stuff. And I think that that’s what they meant at the end of that comment too.
Gotcha. I totally agree with the sentiment, or rather I should say: all these thoughts come to mind when thinking about setting up partial automation for a process, and I regularly remind myself to keep to simple, and get something working.
The hardest to resist is when you have a similar framework in place for another process, but getting a new process to use that framework is still going to take 4x longer (or whatever) than starting from scratch and getting the initial consistency that the do-nothing approach gives.
Yea, I've used similar scripts where if you accidentally put in the wrong email address - oops, now what. You gotta restart the whole script? The script lockin can become a pain point.
It would also be nice if it would show you all the steps beforehand, and then check each item as you progress. Sometimes it's good to actually prepare from a broader perspective.
And it could log into a file as a summary.
So much that could be improved, which is why the simplest solution might be the best.