In praise of –dry-run
by ingve on 1/31/2026, 8:42:13 PM
https://henrikwarne.com/2026/01/31/in-praise-of-dry-run/
Comments
by: mycall
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.
2/1/2026, 1:56:18 AM
by: arjie
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.<p>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.
2/1/2026, 12:32:04 AM
by: ElevenLathe
I usually do the opposite and add a --really flag to my CLI utilities, so that they are read-only by default and extra effort is needed to screw things up.
1/31/2026, 11:58:38 PM
by: BrouteMinou
One of the kick-ass feature of PowerShell is you only need to add `[CmdletBinding(SupportsShouldProcess)] ` to have the `-whatIf` dry-run for your functions.<p>Quite handy.
2/1/2026, 4:10:29 AM
by: CGamesPlay
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.<p>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.
2/1/2026, 2:09:39 AM
by: skissane
In one (internal) CLI I maintain, I actually put the `if not dry_run:` inside the code which calls the REST API, because I have a setting to log HTTP calls as CURL commands, and that way in dry-run mode I can get the HTTP calls it would have made without it actually making them.<p>And this works well if your CLI command is simply performing a single operation, e.g. call this REST API<p>But the moment it starts to do anything more complex: e.g. call API1, and then send the results of API1 to API2 – it becomes a lot more difficult<p>Of course, you can simulate what API1 is likely to have returned; but suddenly you have something a lot more complex and error-prone than just `if not dry_run:`
2/1/2026, 1:11:46 AM
by: cjonas
We have an internal framework for building migrations and the "dry run" it's a core part of the dev cycle. Allows you to test your replication plan and transformations without touching the target. Not to mention, a load that could take >24 hours completes in minutes
2/1/2026, 1:49:06 AM
by: tegiddrone
I’m interested to know the etymology and history of the term. Somehow I imagine an inked printing press as the “wet run.”
2/1/2026, 3:00:08 AM
by: zzo38computer
I think dry run mode is sometimes useful for many programs (and, I sometimes do use them). In some cases, you can use standard I/O so that it is not needed because you can control what is done with the output. Sometimes you might miss something especially if the code is messy, although security systems might help a bit. However, you can sometimes make the code less messy if the I/O is handled in a different way that makes this possible (e.g. by making the functions that make changes (the I/O parts of your program) to handle them in a way that the number of times you need to check for dry run is reduced if only a few functions need to); my ideas of a system with capability-based security would allow this (as well as many other benefits; a capability-based system has a lot of benefits beyond only the security system). Even with the existing security it can be done (e.g. with file permissions), although not as well as capability-based security.
2/1/2026, 12:13:38 AM
by: bikelang
I love `—-dry-run` flags for CLI tooling I build. If you plan your applications around this kind of functionality upfront - then I find it doesn’t have to pollute your code too much. In a language like Go or Rust - I’ll use a option/builder design pattern and whatever I’m ultimately writing to (remote file system, database, pubsub, etc) will instead write to a logger. I find this incredibly helpful in local dev - but it’s also useful in production. Even with high test coverage - it can be a bit spooky to turn on a new, consequential feature. Especially one that mutates data. I like to use dry run and enable this in our production envs just to ensure that things meet the functional and performance qualities we expect before actually enabling. This has definitely saved our bacon before (so many edge cases with prod data and request traffic).
2/1/2026, 12:01:34 AM
by: taude
Funny enough, when creating CLIs with Claude Code (and Github Copilot), they've both added `--dry-run` to my CLIs without me even prompting it.<p>I prefer the inverse, better, though. Default off, and then add `--commit` or `--just-do-it` to make it actually run.
2/1/2026, 1:57:10 AM
by: aappleby
What if the tool required an "un-safeword" to do destructive things?<p>"Do you really want to 'rm -rf /'? Type 'fiberglass' to proceed."
2/1/2026, 2:20:58 AM
by: gooseyman
<a href="https://news.ycombinator.com/item?id=27263136">https://news.ycombinator.com/item?id=27263136</a><p>Related
2/1/2026, 2:42:13 AM
by: throwaway314155
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).
2/1/2026, 2:10:42 AM
by: TZubiri
I use --dry-run when I'm coding and I control the code.<p>Otherwise it's not very wise to trust the application on what should be a deputy responsibility.<p>Nowadays I'd probably use OverlayFS (or just Docker) to see what the changes would be, without ever risking the original FS.
2/1/2026, 2:29:07 AM
by: calvinmorrison
--dry-run<p>--really<p>--really-really<p>--yolo
2/1/2026, 2:15:21 AM
by: awesome_dude
pffft, if you aren't dropping production databases first thing in the morning by accident, how <i>are</i> you going to wake yourself up :-)
2/1/2026, 1:16:04 AM