Live data from Hacker News

In praise of –dry-run

henrikwarne.com

21–30 of 175 posts

Re: In praise of –dry-run

#21
For me the ideal case is three-state. When run interactively with no flags, print a dry run result and prompt the user to confirm the action; and choose a default for non-interactive invocations. In both cases, accept either a --dry-run or a --yes flag that indicates the choice to be made.

This should always be included in any application that has a clear plan-then-execute flow, and it's definitely nice to have in other cases as well.

Re: In praise of –dry-run

#23

Sort of a strange article. You don't see that many people _not_ praising --dry-run (speaking of which, the author should really learn to use long options with a double dash).

I'm not aware of any CLI arguments that accept emdash for long arguments–but I'm here for it. "A CLI framework for the LLM era"

Re: In praise of –dry-run

#25
post #6

In order to make it work without polluting the code-base I find that I have to move the persistence into injectable strategy, which makes it good anyway. If you keep passing in `if dry_run:` everywhere you're screwed. Also, if I'm being honest, it's much better to use `--wet-run` for the production run than to ask people to run `--dry-run` for the test run. Less likely to accidentally fire off the real stuff.

I don't want to have to type rm --wet-run tempfile.tmp every time, or mkdir -p --yes-really-do-it /usr/local/bin The program should default to actually doing whatever thing you're asking it to do. On the other hand it would be great if every tool had an --undo argument that would undo the last thing that program did.

That undo program is called nilfs2, which unfortunately never became popular. I'll simply quote the kernel docs:

> NILFS2 is a log-structured file system (LFS) supporting continuous snapshotting. In addition to versioning capability of the entire file system, users can even restore files mistakenly overwritten or destroyed just a few seconds ago.

https://docs.kernel.org/filesystems/nilfs2.html

https://wiki.archlinux.org/title/NILFS2

https://en.wikipedia.org/wiki/NILFS

Re: In praise of –dry-run

#26
post #6

In order to make it work without polluting the code-base I find that I have to move the persistence into injectable strategy, which makes it good anyway. If you keep passing in `if dry_run:` everywhere you're screwed. Also, if I'm being honest, it's much better to use `--wet-run` for the production run than to ask people to run `--dry-run` for the test run. Less likely to accidentally fire off the real stuff.

I don't want to have to type rm --wet-run tempfile.tmp every time, or mkdir -p --yes-really-do-it /usr/local/bin The program should default to actually doing whatever thing you're asking it to do. On the other hand it would be great if every tool had an --undo argument that would undo the last thing that program did.

Sure, in those cases - but if a command has a chance of nuking prod, you want some extra step in there. Preferably something that can't be muscle-memoried through.

Re: In praise of –dry-run

#28
post #14

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.

Re: In praise of –dry-run

#30
post #14

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.

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