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'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.

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.

Yeah I'm more of a `--wet-run` `-w` fan myself. But it does depend on how serious/annoying the opposite is.

This is something I learnt here.

My latest script which deletes the entire content of a downloaded Sharepoint (locally only) and the relevant MS365 account from the computer runs by default in a read-only mode. You have to run it with an explicit flag to allow for changes.

Also, before it actually deletes the account, you need to explicitly type DELETE-ACCOUNT in order to confirm that this is indeed your intent.

So far, nobody managed to screw up, even in heated situations at client's place.

Just don’t randomly mix and match the approaches or you are in for a bad time.