4 ms·

It's great, but it can't be interrupted. It would also be nice if it would show you all the steps beforehand, and then check each item as you progress. Sometim

It's great, but it can't be interrupted. 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.

gertlex 2y ago
Are these actual criticisms of the article? And you leave us hanging: which solution is the "simplest solution"?
- codetrotter 2y ago
  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.
  - qwertox 2y ago
    Yes, this was what I meant. Sorry to your parent commenter for not being explicit. (Then again, I'd do this in Obsidian.)
    - gertlex 2y ago
      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.
IanCal 2y ago
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.
vagab0nd 2y ago
> but it can't be interrupted 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?
- mwdomino 2y ago
  I’ve just switched to using just https://github.com/casey/just https://github.com/casey/just for my makefiles that were really just a collection of small snippets and it’s worked wonderfully
- pigeons 2y ago
  Just?
chikere232 2y ago
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
david422 2y ago
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.

gertlex 2y ago

Are these actual criticisms of the article? And you leave us hanging: which solution is the "simplest solution"?

codetrotter 2y ago
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.
- qwertox 2y ago
  Yes, this was what I meant. Sorry to your parent commenter for not being explicit. (Then again, I'd do this in Obsidian.)
  - gertlex 2y ago
    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.

IanCal 2y ago

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.

vagab0nd 2y ago

> but it can't be interrupted 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?

mwdomino 2y ago
I’ve just switched to using just https://github.com/casey/just https://github.com/casey/just for my makefiles that were really just a collection of small snippets and it’s worked wonderfully
pigeons 2y ago
Just?

chikere232 2y ago

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

david422 2y ago

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.