111–120 of 126 posts
Why do I think that writing a script in Expect ( https://en.wikipedia.org/wiki/Expect ) would take as long as doing this and then you would be done?
..because you've never tried using expect in anger?
It seems to me that all you want is to document a manual process. Having them documented in dump scripts is no different than having them documented as a guide in your knowledge base .e.g in Confluence or as product requirements. I can see the usage in an isolated team of a few people that will write these scripts for their own benefit. I am opposed in general with having scarce information around. Better have everyt…
You can keep these scripts versioned in a repository next to the actual product code, with all benefits like forking, merging and pull-request reviews.
We use this at my place, though in bash, and we call it executable documentation. Stuff like: NAME="$1" # Create directory for the code mkdir "$NAME" # Checkout the source cd $NAME && git something # and so on Sometimes with an echo "You need to read and understand this before just using it"; exit 1 thrown in somewhere for good measure. These files will have no logic, and make very little use of variables. They will…
You could prefix the script with `#!/bin/bash -vn` and make it executable. It will just print itself.
Earlier quoted context omitted.
But these steps already do nothing except say echo what should be done. How does that differ from your "literally do nothing" steps?
In a truly minimal system, there isn't even a prompt. A code comment is about as minimal as I know how to get. That's just a placeholder to remember to automate a step. When automating a complex manual process, the first thing I do is write comments describing the sequence, and any parameters needed. Parameters in particular can be enlightening, because when manual processes grow organically, naming consistency becom…
Earlier quoted context omitted.
"maybe"..."in the future" is the root of much object oriented evil
I don't think there is a correct answer, but I like that a developer has foresight.
Earlier quoted context omitted.
In a truly minimal system, there isn't even a prompt. A code comment is about as minimal as I know how to get. That's just a placeholder to remember to automate a step. When automating a complex manual process, the first thing I do is write comments describing the sequence, and any parameters needed. Parameters in particular can be enlightening, because when manual processes grow organically, naming consistency becom…
Printing means you can run the script as-is, and any bits which aren't done automatically are prompted for. Just putting comments describing the steps would be like writing a README except in a more esoteric format and would defeat the primary benefit of the approach outlined in TFA.
I'm not saying the original approach is bad. I'm saying it's not the simplest thing that can possibly work. I'm talking about how to move to automation, not how to reduce errors on the manual process. Both are needed.
Earlier quoted context omitted.
Yes, very much so. In addition stop using RSA[0] and use ed25519 with `ssh-keygen -t ed25519` [0]: https://blog.trailofbits.com/2019/07/08/fuck-rsa/
Unless you're using a hardware token via gpg-agent. In that case RSA is the only way most of the time.
I can't help looking at this and working out how to build a tool that can generate a Do Nothing script straight from your histfile, making the business of archiving the commands you just executed as easy as possible too...
Reminds me of the time I decided to try kanban to start moving forward on tasks I procrastinate on or have trouble starting. Of course, to make sure it was efficient enough to be helpful it had to be a configurable terminal app I could quickly update and review via cli and abundant io flags/options. It also made sense to write it in Scheme because I had been thinking I wanted to try Lisp earlier that day. Fast-forwar…