Comment by mycall
Comment by mycall 5 hours ago
I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.
Comment by mycall 5 hours ago
I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.
I wouldn’t want most things to work this way:
$ rm file.bin
$ rm —-commit file.bin
$ cat foo.txt > bar.txt
$ cat foo.txt | tee —-write-for-real bar.txt
$ cp balm.mp3 pow.mp3
$ cp —-i-mean-it balm.mp3 pow.mp3
There is a time and a place for it but it should not be the majority of use cases.Totally agree it shouldn't be for basic tools; but if I'm ever developing a script that performs any kind of logic before reaching out to a DB or vendor API and modifies 100k user records, creating a flag to just verify the sanity of the logic is a necessity.
Yep. First thing I do for this kind thing is make a preview=true flag so I don’t accidentally run destructive actions.
For most of these local data manipulation type of commands, I'd rather just have them behave dangerously, and rely on filesystems snapshots to rollback when needed. With modern filesystems like zfs or btrfs, you can take a full snapshot every minute and keep it for a while to negate the damage done by almost all of these scripts. They double as a backup solution too.
I have a parallel directory deduper that uses hard links and adopted this pattern exactly.
By default it'll only tell you which files are identical between the two parallel directory structures.
If you want it to actually replace the files with hard links, you have to use the --execute flag.
There was a tool I used some time ago that required typing in a word or phrase to acknowledge that you know it's doing the run for real.
Pros and cons to each but I did like that because it was much more difficult to fat finger or absentmindedly use the wrong parameter.
--with-danger
--make-it-so
--do-the-thing
--go-nuts
--safety-off
So many fun options.
I've done a few --execute --i-know-what-im-doing for some more dangerous scripts
May I recommend --I-take-responsibility-for-the-outcome-of-proceeding and require a capital I?
I've biased towards this heavily in the last 8 or so years now.
I've yet to have anyone mistakenly modify anything when they need to pass --commit, when I've repeatedly had people repeatedly accidentally modify stuff because they forgot --dry-run.