Very clever, but the sensible thing to do is never rely on one-liners, lest you end up in this kind of situation. Get that thinking out of your head. Always write the script (that's why it's called "the script" ... ) in a file and use that.
This is why every major project I work on has a ".archive/oneshot/" folder for anything complicated that was used to quickly put out a fire. Not only will I inevitably need to remember months later what happened, but I'll also want to reuse certain bits later.
That ".archive" folder itself is then a personal git repo. Sometimes you just have to put that fire out or get that question answered and its not worth a "proper" solution, but keeping a history is worth it.
Resist the urge to keep it as part of the main project's repo at all costs. It's far too easy for it to be come standardized (e.g. by other devs, perhaps) and breath life into them they should never have.
Exactly, I just wrote a blog post about how I do that, basically with shell scripts in the repo with lots of small functions. They basically form an annotated log of what I did, so I never have to remember long commands.
I can't remember long commands so I always write them down.
Examples of using a JSON API, using a C++ tool uftrace, and hacking on Kernighan's awk:
Admittely there are a lot of people who don't seem to like reading shell scripts as docs. But you don't really have to read the code -- you just read the function names.
I also added doc comments to Oil, like this:
deploy() {
### doc comment
cp foo bar
}
which you can access with the 'pp' builtin. So eventually those strings could be exposed to autocomplete, etc.
