4 ms·
Wow, I'm seriously considering adapting this for my shell scripts (with code recovery via mercurial, since I'm weak of will...). Actually, I bet there are alre
by rcbarnes 14y ago
Wow, I'm seriously considering adapting this for my shell scripts (with code recovery via mercurial, since I'm weak of will...). Actually, I bet there are already others doing the same, because code deletion in personal shell scripts probably turns out to be an unalloyed good.
Consider this: you've got some script that does a sequence of operations using the standard tools. Somewhere you change between imagemagick and graphicsmagick and some image doesn't get made thanks to syntax differences; after this you've used some clever shell filename expansion expression or regex to move/delete files, but the missing image changed your working context enough that suddenly you're in $HOME doing an rm -rf .! The environment is just too fragile and powerful to completely automate everything you might need without setting up enough safety mechanisms, confirmations, and sanity checks to largely nullify the value of scripting as a nearly zero development programming toolchain.
But if shell code were trivially spec'd for pre-/post- conditions and misbehaving code gets noisily deleted (noisily so everything isn't packed away into code versioning purgatory by cascading failures when a tool like rename is accidentally uninstalled)---especially if the shell of pre-and post conditions were left around stub code... Imagine the beauty of your scripts directory!
Replacing some slain block of code is trivial since the tools you need are already mostly written, and you've done something close to what you need before---plus the whole point of shell scripting is that it should be effortless and fast to produce.
If you've built a massive, multi-purpose utility, it deserves to live only as long as it runs flawlessly---after which, you should slice it down or replace it with an inevitably more reliable equivalent that was written for the same purpose years (or decades) ago.
Best of all the conditions that deleted your broken cruft even remind you exactly what you needed to do when you're re-implementing something, but often without pre-studying the entire system to ascertain what world state you are getting and what you need to produce. Brilliant!
This may have started out somewhat tongue-in-cheek (since most programming environments are at least somewhat stable and feature significant error detection and recovery facilities), but I think there's some dead serious application in the quick-and-dirty, often unchecked and fluid environment of traditional shell scripting. The more I think about it, the more I'm amazed my quarter million keystrokes of live scripts woven into my every task on my Linux desktop haven't produced more catastrophes (or any meaningful accidental data loss) or left a trail of silent failures for me to find only long after the causal bugs had manifested.
- munificent 14y ago> somewhat tongue-in-cheek Somewhat?
- rcbarnes 14y agoWell, from what I gather, the overarching criteria of the contest for which this was develped is "Does it do something novel to advance understanding and execution of software development?" While that kind of focus tends to bring out all kinds of wacky ideas, don't confuse defiance of the status quo for casting off all reason. When there's no shame in it, experimenters needen't rationalize or smooth over their deviation from expected norms.
- munificent 14y ago> "Does it do something novel to advance understanding and execution of software development?" Shit, I probably should have read the rules before I entered.