Hacker News Reader

Comment by nicoburns | Hacker News Reader

For particularly dangerous operations, even better is to make dry run the default, and force users to explicitly opt-in to actually running it.

View on HN

I've done that and called the counter option --for-real, but I'd like both args so runbooks can spell out:

    1. do-step-one --dry-run
    2. (do validation)
    3. do-step-one --real-run
    4. (do validation)

Many commandline parsing libraries assume you're doing booleans, and I think --dry-run and --no-dry-run is confusing. And, internally, you have a boolean flag so there's always the possibility of some code getting it backwards.

Internally, I'd like an enum flag that's clearly dry_run or real_run, so the guards are using positive logic:

    switch(run) {
      case dry_run:
        print("Would do this...");
      case real_run:
        do_real_thing();
    }

coughs gently I use `DryRunMode.Dry` and `DryRunMode.Wet` in the OP.

I think the point here, though, is that the user needs to be explicit on the command line: they have to specify one of `--wet` or `--dry`; specifying neither is an error. It's not clear from your code if you do that, or if you interpret `--dry-run` as `DryRunMode.Dry` and the absence of an option as `DryRunMode.Wet`.

While I kinda like this idea in principle, I haven't really seen any CLI apps that require an explicit option for both modes, so it might be a bit of unexpected UX for people.

I noticed that after I posted and had read a bit more; but you're also using F# which has proper ADTs. I'm typically writing support scripts in Python or the like, and even very good libraries like click[1] nevertheless reflect the idioms popular in the language.

I really came back to this post because I was struggling with Gradle and if there is a more perfect illustration of how a dry run mode could help than that, I don't know what it could be. Gradle builds are a fucking mystery, every time, and there's no excuse for it.

[1]: https://palletsprojects.com/p/click/

I've written a couple tools that default to dry run and require `--yes-actually-delete` and similar, but I can't think of any publicly available tools that follow this pattern - anybody have suggestions?

Not quite the same, but apt commands like apt-get require user interaction to confirm what you are about to do, unless you explicitly add a "-y" / "--yes" to the command.

apt will sometimes prompt you to confirm really dangerous options too:

       sudo apt-get purge login
       ..
       WARNING: The following essential packages will be removed.
       This should NOT be done unless you know exactly what you are doing!
         login
       0 upgraded, 0 newly installed, 1 to remove and 303 not upgraded.
       After this operation, 1,212 kB disk space will be freed.
       You are about to do something potentially harmful.
       To continue type in the phrase 'Yes, do as I say!'
        ?]

sed does not operate on files directly unless turned (-i)nteractive.

-i is short for --in-place

Minor quibble the -i option mnemonic is "in-place" rather than "interactive".

oh good one, prettier does the same thing - output to stdout unless --write is set

I only use sed on version controlled files and immediately run git diff afterwards to check the results.

Also not quite the same, but `git clean` bails out extremely early unless you supply one of -i, -f, or -n (the latter of which is `--dry-run`).

”git clean” sort-of works like this. It errors out unless you explicitly specify if it’s a real run or dry run.

`git push` in cases of conflict too.

rm has "--no-preserve-root", which isn't quite "--no-seriously-delete-my-root-directory" but is at least heading in that direction.

if you squint, you can kind of see file permissions as implementing this pattern? rm /usr fails unless you sudo rm /usr

Obligatory Cantrill reference https://youtu.be/wTVfAMRj-7E?t=5046. The whole series of these are well worth a listen.

Not exactly the same, but along the same lines: mysql has an --i-am-a-dummy flag so that DELETE queries won't run without a WHERE.

https://github.com/dmerejkowsky/ruplacer

Uses `--go` to confirm.

Perforce’s command line app uses this pattern for one of its most dangerous commands: p4 obliterate //depot/path/... which prints out exactly which files will be obliterated from the server (which not only removes their entire history, but can corrupt other files too if you don’t p4 snap them first).

To actually carry out the obliterate action, you have to add the -y option.

`hdparm --yes-i-know-what-i-am-doing --please-destroy-my-drive --fwdownload`

https://github.com/Distrotech/hdparm/blob/4517550db29a91420f...

React has a deliberately inconvenient API for injecting unsanitized HTML markup straight into the DOM:

    <div dangerouslySetInnerHTML={{ __html: "Some raw HTML" }}></div>

https://reactjs.org/docs/dom-elements.html#dangerouslysetinn...

It’s a good opportunity to use long options like:

—i-acknowledge-this-is-dangerous-and-i-gave-this-more-than-cursory-thought

I don't like this because it trains users to assume that commands can never do dangerous stuff by default.

Definitely true. In this case, it's important to vet guides/examples to make sure you minimize copypastable examples that have the --no_dry_run flag

Yep, this is what I do now. The dry run is the default, you have to flag `--really` to do anything permanent.

Reply on news.ycombinator.com