7 ms·

In praise of –dry-run

309 points by ingve 9mo ago

ElevenLathe 9mo ago
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.
- weikju 9mo ago
  Came here to say the same
- eichin 9mo ago
  I've committed "--i-meant-that" (for a destroy-the-remote-machine command that normally (without the arg) gives you a message and 10s to hit ^C if you're not sure, for some particularly impatient coworkers. Never ended up being used inappropriately, which is luck (but we never quantified how much luck :-)
  - tkclough 9mo ago
    I like the timer idea. I do something kinda similar by prompting the user to enter some short random code to continue. I guess the goal for both is to give the user a chance to get out of autopilot, and avoid up-arrowing and re-executing.
bikelang 9mo ago
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).
zzo38computer 9mo ago
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.
arjie 9mo ago
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.
- segmondy 9mo ago
  this is where design patterns come in handy even tho folks roll their eyes at it.
  - cake-rusk 9mo ago
    Design patterns exist to paper over language deficiencies. Use a language which is not deficient.
    - antinomicus 9mo ago
      Like what?
      - frogulis 9mo ago
        First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns
      - cake-rusk 9mo ago
        Here you go: https://fsharpforfunandprofit.com/fppatterns/ https://fsharpforfunandprofit.com/fppatterns/
    - WCSTombs 9mo ago
      There's some truth to this, since some design patterns can simply be implemented "for good" in a sufficiently powerful language, but I don't find it's true in general. Unfortunately, it has become something of a thought-terminating cliché. Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win.
skissane 9mo ago
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. And this works well if your CLI command is simply performing a single operation, e.g. call this REST API 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 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:`
- scruple 9mo ago
  Having 1 place (or just generally limiting them) that does the things keeps the dry_run check from polluting the entire codebase. I maintain a lot of CLI tooling that's run by headless VMs in automation pipelines and we do this with basically every single tool.
- iberator 9mo ago
  What's your obsession with REST AND HTTP for console tools?! Rest bloat is insane. Kidss nowadays wants EVERYTHING to run over IP/TCP/https. Why?! Learn to write local tools first.
awesome_dude 9mo ago
pffft, if you aren't dropping production databases first thing in the morning by accident, how are you going to wake yourself up :-)
cjonas 9mo ago
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
mycall 9mo 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.
- Twirrim 9mo ago
  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.
  - IgorPartola 9mo ago
    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.
    - Darfk 9mo ago
      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.
      - james_marks 9mo ago
        Yep. First thing I do for this kind thing is make a preview=true flag so I don’t accidentally run destructive actions.
        mycall 9mo ago
        Now I like that idea as an environment variable that takes precedence over the command parameters.
taude 9mo ago
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. I prefer the inverse, better, though. Default off, and then add `--commit` or `--just-do-it` to make it actually run.
CGamesPlay 9mo ago
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.
throwaway314155 9mo ago
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).
- CGamesPlay 9mo ago
  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"
  - deleted 9mo ago
    [deleted]
- analog31 9mo ago
  I only saw the emdash in the thread link, but I do know that an iPad "wants" to turn a double dash into an emdash automatically. I have no idea how to disable that default.
  - xigoi 9mo ago
    If you’re using an iPad, the implicit assumption is that Apple knows better than you what you want to do.
calvinmorrison 9mo ago
--dry-run --really --really-really --yolo
- homebrewer 9mo ago
  You'll like fontconfig then, which has both --force and --really-force https://man.archlinux.org/man/fc-cache.1.en https://man.archlinux.org/man/fc-cache.1.en
TZubiri 9mo ago
I use --dry-run when I'm coding and I control the code. Otherwise it's not very wise to trust the application on what should be a deputy responsibility. Nowadays I'd probably use OverlayFS (or just Docker) to see what the changes would be, without ever risking the original FS.
- throwaway290 9mo ago
  How do you easily diff what changed between Docker and host?
  - TZubiri 9mo ago
    The way OverlayFS works is that there's a base directory. And then there's an overlay directory that only contains the changes. Docker is based on OverlayFS. There's two main ways overlays are used, first at build time, each line/command generates a new overlay based on the previous base, so when you do something like FROM debian RUN apt-get update it creates a base from the debian image , and then creates an overlay that only contains the changes introduced by apt-get update. If you use docker inspect or docker show on the image you get a json showing exactly where the overlay directories are, you just need to navigate the overlay directory. Second: on runtime. [Assuming you are not using volumes, (and if you use volumes, just make sure the volume starts out as empty, instead of sharing your host files)] OverlayFS is used for the runtime file changes as well, the last image is used as a base, and every files changed during runtime are added to the runtime overlay. That filesystem won't be deleted, if you only stop the docker container, the runtime files will still be present, and you can reach them by docker inspecting the running docker processes/instances, and then navigating the overlay fs as you would any directory. You can also just use overlayfs, as far as I recall, you just use mount and unmount while specifying the OverlayFS driver and special parameters like base and overlay. Conjugating a chain of overlays is a bit more complex, but it's the same interface.
    - throwaway290 9mo ago
      Thanks!
aappleby 9mo ago
What if the tool required an "un-safeword" to do destructive things? "Do you really want to 'rm -rf /'? Type 'fiberglass' to proceed."
- nthdeui 9mo ago
  Like tarsnap's --nuke command: --nuke Delete all of the archives stored. To protect against accidental data loss, tarsnap will ask you to type the text "No Tomorrow" when using the --nuke command.
  - drougge 9mo ago
    Probably inspired by Vinum's "NO FUTURE" for destructive operations. (Vinum was a raid system used on older versions of FreeBSD.)
- jabroni_salad 9mo ago
  There is a package called molly-guard that makes you type the computer's hostname when you are trying to do a shutdown or restart. I love it.
gooseyman 9mo ago
https://news.ycombinator.com/item?id=27263136 https://news.ycombinator.com/item?id=27263136 Related
tegiddrone 9mo ago
I’m interested to know the etymology and history of the term. Somehow I imagine an inked printing press as the “wet run.”
- jofzar 9mo ago
  Interestingly the one place I have seen "dry run" to actually mean "dry run" is using a air compressor to check to see if a water loop (in a computer) doesn't leak by seeing if there no drop in pressure.
- hydrox24 9mo ago
  It seems to have originated in the US with Fire Departments: > These reports show that a dry run in the jargon of the fire service at this period [1880s–1890s] was one that didn’t involve the use of water, as opposed to a wet run that did. https://www.worldwidewords.org/qa/qa-dry1.htm https://www.worldwidewords.org/qa/qa-dry1.htm
BrouteMinou 9mo ago
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. Quite handy.
- debugnik 9mo ago
  Even better, it enables both -WhatIf and -Confirm, and provides a ShouldProcess function that interacts with both and with the user's impact threshold preferences. Really cool.
- tonymet 9mo ago
  Powershell cmdlet macros (and the resultant parameter consistency with flags and verbs) are a great example that should make its way over to bash/zsh scripts. Given we are rewriting so many Unix utilities, it would be a great time to learn from a positive example.
alexhans 9mo ago
Agreed. For me a good help, a dry run and a readme with good examples has been the norm for work tools for a while. It's even more relevant now that you can get the LLMs/CLI agents to use your deterministic CLI tools.
mystifyingpoi 9mo ago
I like doing the same in CI jobs, like in Jenkins I'll add a DRY_RUN parameter, that makes the whole job readonly. A script that does the deployment would then only write what would be done.
calebhwin 9mo ago
And it's more important than ever in the age of coding agents.
sixtram 9mo ago
I use a similar strategy for API design. Every API call is wrapped in a large database transaction, and I either roll back or commit the transaction based on dry-run or wet-run flags. This works well as long as you don’t need to touch the file system. I even wrap emails this way—emails are first written to a database queue, and an external process picks them up every few seconds.
- sixtram 9mo ago
  To continue, this design has additional benefits: The code is not littered with dry-run flag checks; the internal code doesn’t even know that a dry run is possible. Everything is rolled back at the end if needed. All database referential integrity checks run correctly. Some drawbacks: any audit logging should run in a separate transaction if you want to log dry runs.
xavdid 9mo ago
I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me. Put another way: your dry code should do everything up until the point that database writes / API calls / etc actually happen. Don't bail too early
- marhee 9mo ago
  Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.
  - xavdid 9mo ago
    Yes, but it depends on the context. For little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.
    - AmbroseBierce 9mo ago
      You understand how subjective that is right? Someone might expect that the database doesn't do the last commit step while other people is perfectly happy that the database engine checks that it has enough writing permissions and is running as a user that can start the process without problems.
      - xavdid 9mo ago
        Sure, where you draw the line will vary between projects. As long as its exact placement doesn't matter too much. For me personally, I tend to draw the line at write operations. So in your example, I'd want a dry run to verify the permissions that it can (if I expect those to be a problem). But if that can't easily be done without a write, then maybe it's not worth it. There are also situations where you want a dry run to be really fast, so you forego some checks (allowing for more surprises later). Really just depends.
giorgioz 9mo ago
I didn't know about --dry-run until last summer Claude Code added it to a script it had created.
bjt12345 9mo ago
I like to use the term "--no-clobber", so to set a script to not delete any information but re-use the previous configuration or files, otherwise error out if not possible.
muvlon 9mo ago
If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back. As a nice bonus, this pattern gives a good answer to the problem of having "if dry_run:" sprinkled everywhere: You have to separate the planning and execution in code anyway, so you can make the "just apply immediately" mode simply execute(plan()).
- Jolter 9mo ago
  I like that idea! For an application like Terraform, Ansible or the like, it seems ideal. For something like in the article, I’m pretty sure a plan mode is overkill though. Planning mode must involve making a domain specific language or data structure of some sort, which the execution mode will interpret and execute. I’m sure it would add a lot of complexity to a reporting tool where data is only collected once per day.
  - muvlon 9mo ago
    No need to overthink it. In any semi-modern language you can (de)serialize anything to and from JSON, so it's really not that hard. The only thing you need to do is have a representation for the plan in your program. Which I will argue is probably the least error-prone way to implement --dry-run anyway (as opposed to sprinkling branches everywhere).
    - Jolter 9mo ago
      Right, but you still have to define every ”verb” your plan will have, their ”arguments”, etc. Not need to write a parser (even Java can serialize/deserialize stuff), as you say, but you have to meta-engineer the tool. Not just script a series of commands.
rook_line_sinkr 9mo ago
Dry run is great, but if you are using your script in a serious pipeline like that, you may want to go tho extra mile and write tests https://github.com/shellspec/shellspec https://github.com/shellspec/shellspec
spwa4 9mo ago
I would love to have this available in git. I know if you make mistakes you can use the reflog, but if you need 5 tries to get something right reading the reflog quickly becomes impossible. Plus there are operations, like rebase or merge, that feel the need to make 50 entries in the reflog. I've resorted to copying the entire directory (including the .git part) and then trying on the copy. The issue is that I'm working on a C++ program that has a few gigabytes of data.
- joombaga 9mo ago
  Consider using work trees. They have separate reflogs, you'd still get separate directories, but less duplication.
d7w 9mo ago
Funny, I recalled a tool called "molly-guard" which solves the problem when you want to reboot a Unix server, but can be on the wrong one. It asks to type the server name. Anybody who rebooted a wrong server can say that this tool is brilliant. Like "--dry-run" but for "reboot."
- fainpul 9mo ago
  These kind of obstacles don't work for any action that the user does repeatedly. Dialogs that pop up and ask "Are you sure you want to delete ...?" -> users just automatically click yes, because they already did that the last 10 times and just want to get on with their work. Logged in to server "alpha" instead of "delta" because you thought that's the right one. Tool asks you to write the server name. You type "alpha" because you know you're on alpha. Reboots the wrong server. Github ask you to confirm the repo name before deleting by typing it into a text field. User looks at what the repo name is and types it without thinking. Or, like lazy me, mark and drag the displayed name into the field, so you don't even have to type. The point is, users already decided to do the action when they started. It's nearly impossible to consistently make them stop and re-evaluate their decision, because that's extremely high friction and annoying. They quickly learn to circumvent the friction as efficiently as possible (i.e. without thinking about it). A better solution is to just do it, but let the user undo it if it was a mistake (not always possible of course).
  - d7w 9mo ago
    > Or, like lazy me, mark and drag the displayed name into the field Yes, the same, unfortunately. This rail guard works for only a couple of days or weeks when the perception is fresh. After that, it's always "select, copy, paste, confirm" without thinking. I believe the better approach is to practice "Chaos Monkeys" and improve the infrastructure to survive even if someone makes a mistake.
  - Mawr 9mo ago
    > Github ask you to confirm the repo name before deleting by typing it into a text field. User looks at what the repo name is and types it without thinking. Or, like lazy me, mark and drag the displayed name into the field, so you don't even have to type. Pretty easy to solve this sort of stuff with timers: "Sure, the repo will be deleted in <timer>. Press here to abort: <button>." Or have the timers on the backend and just show the user an undo button.
clawsyndicate 9mo ago
[dead]
Arbortheus 9mo ago
I prefer “—really-do”, so the default behaviour of the tool is to do nothing. That’s more fault tolerant for the scenario you forget to add “—dry-run”.
- nvader 9mo ago
  At a previous org, Boolean arguments could be toggled with the [no] prefix. The default for dry-run could be set to True, and then you had to type: ``` --nodry-run ``` Cut to, a new engineer asking me "Who is Nodry?"
  - SoftTalker 9mo ago
    How about --i-might-lose-my-job-if-i-fuck-this-up ?
jaynate 9mo ago
> The downside is that the dryRun-flag pollutes the code a bit. In all the major phases, I need to check if the flag is set, and only print the action that will be taken, but not actually doing it. Sounds like a case for the state machine pattern
dabedee 9mo ago
From the article: "I added –dry-run on a whim early on in the project. I was surprised at how useful I found it to be." Not to be overly critical (I think it's great OP found value in adding and using --dry-run), but I am willing to bet that this was a suggestion/addition from a coding agent (and most likely Claude code/Opus). Having used it myself to build various CLI tools in different languages, it almost always creates that option when iterating on CLIs. To the point where it's almost a tell. I wonder if we're entering a moment of convergence where all the tools will have similar patterns/options because they are similarly written by agents.
- SPBS 9mo ago
  > Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option. > I remembered how helpful that was, so I decided to add it to my command as well. He mentions the reason he added it, and it's a compelling enough story to be true.
  - dabedee 9mo ago
    Of course and I am not trying to point fingers. But I do think it's interesting because it's also possible that it is confabulation. Not lying, but genuinely constructing coherent explanations for decisions whose true origins are different than we recall. I think working with coding agents has already made this immensely more common.
    - mpyne 9mo ago
      I had the equivalent of --dry-run in my kdecvs-build script from 2003 (where it was called --pretend) so it's not that spontaneous an idea that it must have been dreamed up by an AI. Any time you have a script that needs to run for a long time or might involve destructive actions, having a way to run the script in a "tell me what you would do without actually doing it" mode is a fairly obvious user story to throw in.
      - 9mo ago
devcraft_ai 9mo ago
[flagged]
techpulse_x 9mo ago
[flagged]
nickjj 9mo ago
One thing that I didn't see mentioned is making your own dry run for tools that don't have it built in. It doesn't always work but sometimes I use `diff` to help with that. For example, if you have a complicated `sed` replacement that you plan to run on a file, you can use diff like this `diff -u <(echo "hello") <(echo "hello" | sed "s/hello/hi/g")` to help show what has changed. I've written about the value of dry run too at: https://nickjanetakis.com/blog/cli-tools-that-support-previews-dry-runs-or-non-destructive-actions https://nickjanetakis.com/blog/cli-tools-that-support-previe...
whalesalad 9mo ago
The fact that every single `--` has become — drives me bananas. For a technical blog this oversight is so sloppy.
terrabitz 9mo ago
A while ago when I was working with PowerShell a lot, I got spoiled by the easy inclusion of `-DryRun` flags in all my scripts. Nowadays I still use the technique for a lot of the tools I make. I typically do a Terraform-like approach: create a plan, validate the plan, render the plan to the user, exit early if we're in dry-run mode, and apply the plan as the final step. Whether dry-run is enabled by default depends on the risk of the operations and who will be using the tool. This makes it exceedingly clear what actions the tool will do. Plus it has the added benefit of being able to split the plan and apply steps into two separate steps. For example, you can create a plan, serialize it to JSON, store it (e.g. in VCS, Jira ticket, whatever) then apply it during a change window. plan = createPlan() print(plan.string()) if (dryRun){ return } plan.apply()
amelius 9mo ago
In even more praise of Ctrl+Z. (Don't try it in a terminal window, though)
- deleted 9mo ago
  [deleted]
mfonda 9mo ago
If the changes your command makes are strictly to a relational database, then `--dry-run` becomes quite easy to implement: just start a transaction and never commit it. This avoids polluting the entire command with `if dryRun` checks everywhere. I've found this to be a great approach.

309 points by ingve 9mo ago

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.

weikju 9mo ago
Came here to say the same
eichin 9mo ago
I've committed "--i-meant-that" (for a destroy-the-remote-machine command that normally (without the arg) gives you a message and 10s to hit ^C if you're not sure, for some particularly impatient coworkers. Never ended up being used inappropriately, which is luck (but we never quantified how much luck :-)
- tkclough 9mo ago
  I like the timer idea. I do something kinda similar by prompting the user to enter some short random code to continue. I guess the goal for both is to give the user a chance to get out of autopilot, and avoid up-arrowing and re-executing.

bikelang 9mo ago

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

zzo38computer 9mo ago

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.

arjie 9mo ago

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.

segmondy 9mo ago
this is where design patterns come in handy even tho folks roll their eyes at it.
- cake-rusk 9mo ago
  Design patterns exist to paper over language deficiencies. Use a language which is not deficient.
  - antinomicus 9mo ago
    Like what?
    - frogulis 9mo ago
      First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns
    - cake-rusk 9mo ago
      Here you go: https://fsharpforfunandprofit.com/fppatterns/ https://fsharpforfunandprofit.com/fppatterns/
  - WCSTombs 9mo ago
    There's some truth to this, since some design patterns can simply be implemented "for good" in a sufficiently powerful language, but I don't find it's true in general. Unfortunately, it has become something of a thought-terminating cliché. Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win.

skissane 9mo ago

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. And this works well if your CLI command is simply performing a single operation, e.g. call this REST API 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 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:`

scruple 9mo ago
Having 1 place (or just generally limiting them) that does the things keeps the dry_run check from polluting the entire codebase. I maintain a lot of CLI tooling that's run by headless VMs in automation pipelines and we do this with basically every single tool.
iberator 9mo ago
What's your obsession with REST AND HTTP for console tools?! Rest bloat is insane. Kidss nowadays wants EVERYTHING to run over IP/TCP/https. Why?! Learn to write local tools first.

awesome_dude 9mo ago

pffft, if you aren't dropping production databases first thing in the morning by accident, how are you going to wake yourself up :-)

cjonas 9mo ago

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

mycall 9mo 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.

Twirrim 9mo ago
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.
- IgorPartola 9mo ago
  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.
  - Darfk 9mo ago
    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.
    - james_marks 9mo ago
      Yep. First thing I do for this kind thing is make a preview=true flag so I don’t accidentally run destructive actions.
      - mycall 9mo ago
        Now I like that idea as an environment variable that takes precedence over the command parameters.

taude 9mo ago

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. I prefer the inverse, better, though. Default off, and then add `--commit` or `--just-do-it` to make it actually run.

CGamesPlay 9mo ago

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.

throwaway314155 9mo ago

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

CGamesPlay 9mo ago
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"
- deleted 9mo ago
  [deleted]
analog31 9mo ago
I only saw the emdash in the thread link, but I do know that an iPad "wants" to turn a double dash into an emdash automatically. I have no idea how to disable that default.
- xigoi 9mo ago
  If you’re using an iPad, the implicit assumption is that Apple knows better than you what you want to do.

calvinmorrison 9mo ago

--dry-run --really --really-really --yolo

homebrewer 9mo ago
You'll like fontconfig then, which has both --force and --really-force https://man.archlinux.org/man/fc-cache.1.en https://man.archlinux.org/man/fc-cache.1.en

TZubiri 9mo ago

I use --dry-run when I'm coding and I control the code. Otherwise it's not very wise to trust the application on what should be a deputy responsibility. Nowadays I'd probably use OverlayFS (or just Docker) to see what the changes would be, without ever risking the original FS.

throwaway290 9mo ago
How do you easily diff what changed between Docker and host?
- TZubiri 9mo ago
  The way OverlayFS works is that there's a base directory. And then there's an overlay directory that only contains the changes. Docker is based on OverlayFS. There's two main ways overlays are used, first at build time, each line/command generates a new overlay based on the previous base, so when you do something like FROM debian RUN apt-get update it creates a base from the debian image , and then creates an overlay that only contains the changes introduced by apt-get update. If you use docker inspect or docker show on the image you get a json showing exactly where the overlay directories are, you just need to navigate the overlay directory. Second: on runtime. [Assuming you are not using volumes, (and if you use volumes, just make sure the volume starts out as empty, instead of sharing your host files)] OverlayFS is used for the runtime file changes as well, the last image is used as a base, and every files changed during runtime are added to the runtime overlay. That filesystem won't be deleted, if you only stop the docker container, the runtime files will still be present, and you can reach them by docker inspecting the running docker processes/instances, and then navigating the overlay fs as you would any directory. You can also just use overlayfs, as far as I recall, you just use mount and unmount while specifying the OverlayFS driver and special parameters like base and overlay. Conjugating a chain of overlays is a bit more complex, but it's the same interface.
  - throwaway290 9mo ago
    Thanks!

aappleby 9mo ago

What if the tool required an "un-safeword" to do destructive things? "Do you really want to 'rm -rf /'? Type 'fiberglass' to proceed."

nthdeui 9mo ago
Like tarsnap's --nuke command: --nuke Delete all of the archives stored. To protect against accidental data loss, tarsnap will ask you to type the text "No Tomorrow" when using the --nuke command.
- drougge 9mo ago
  Probably inspired by Vinum's "NO FUTURE" for destructive operations. (Vinum was a raid system used on older versions of FreeBSD.)
jabroni_salad 9mo ago
There is a package called molly-guard that makes you type the computer's hostname when you are trying to do a shutdown or restart. I love it.

gooseyman 9mo ago

https://news.ycombinator.com/item?id=27263136 https://news.ycombinator.com/item?id=27263136 Related

tegiddrone 9mo ago

I’m interested to know the etymology and history of the term. Somehow I imagine an inked printing press as the “wet run.”

jofzar 9mo ago
Interestingly the one place I have seen "dry run" to actually mean "dry run" is using a air compressor to check to see if a water loop (in a computer) doesn't leak by seeing if there no drop in pressure.
hydrox24 9mo ago
It seems to have originated in the US with Fire Departments: > These reports show that a dry run in the jargon of the fire service at this period [1880s–1890s] was one that didn’t involve the use of water, as opposed to a wet run that did. https://www.worldwidewords.org/qa/qa-dry1.htm https://www.worldwidewords.org/qa/qa-dry1.htm

BrouteMinou 9mo ago

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. Quite handy.

debugnik 9mo ago
Even better, it enables both -WhatIf and -Confirm, and provides a ShouldProcess function that interacts with both and with the user's impact threshold preferences. Really cool.
tonymet 9mo ago
Powershell cmdlet macros (and the resultant parameter consistency with flags and verbs) are a great example that should make its way over to bash/zsh scripts. Given we are rewriting so many Unix utilities, it would be a great time to learn from a positive example.

alexhans 9mo ago

Agreed. For me a good help, a dry run and a readme with good examples has been the norm for work tools for a while. It's even more relevant now that you can get the LLMs/CLI agents to use your deterministic CLI tools.

mystifyingpoi 9mo ago

I like doing the same in CI jobs, like in Jenkins I'll add a DRY_RUN parameter, that makes the whole job readonly. A script that does the deployment would then only write what would be done.

calebhwin 9mo ago

And it's more important than ever in the age of coding agents.

sixtram 9mo ago

I use a similar strategy for API design. Every API call is wrapped in a large database transaction, and I either roll back or commit the transaction based on dry-run or wet-run flags. This works well as long as you don’t need to touch the file system. I even wrap emails this way—emails are first written to a database queue, and an external process picks them up every few seconds.

sixtram 9mo ago
To continue, this design has additional benefits: The code is not littered with dry-run flag checks; the internal code doesn’t even know that a dry run is possible. Everything is rolled back at the end if needed. All database referential integrity checks run correctly. Some drawbacks: any audit logging should run in a separate transaction if you want to log dry runs.

xavdid 9mo ago

I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me. Put another way: your dry code should do everything up until the point that database writes / API calls / etc actually happen. Don't bail too early

marhee 9mo ago
Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.
- xavdid 9mo ago
  Yes, but it depends on the context. For little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.
  - AmbroseBierce 9mo ago
    You understand how subjective that is right? Someone might expect that the database doesn't do the last commit step while other people is perfectly happy that the database engine checks that it has enough writing permissions and is running as a user that can start the process without problems.
    - xavdid 9mo ago
      Sure, where you draw the line will vary between projects. As long as its exact placement doesn't matter too much. For me personally, I tend to draw the line at write operations. So in your example, I'd want a dry run to verify the permissions that it can (if I expect those to be a problem). But if that can't easily be done without a write, then maybe it's not worth it. There are also situations where you want a dry run to be really fast, so you forego some checks (allowing for more surprises later). Really just depends.

giorgioz 9mo ago

I didn't know about --dry-run until last summer Claude Code added it to a script it had created.

bjt12345 9mo ago

I like to use the term "--no-clobber", so to set a script to not delete any information but re-use the previous configuration or files, otherwise error out if not possible.

muvlon 9mo ago

If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back. As a nice bonus, this pattern gives a good answer to the problem of having "if dry_run:" sprinkled everywhere: You have to separate the planning and execution in code anyway, so you can make the "just apply immediately" mode simply execute(plan()).

Jolter 9mo ago
I like that idea! For an application like Terraform, Ansible or the like, it seems ideal. For something like in the article, I’m pretty sure a plan mode is overkill though. Planning mode must involve making a domain specific language or data structure of some sort, which the execution mode will interpret and execute. I’m sure it would add a lot of complexity to a reporting tool where data is only collected once per day.
- muvlon 9mo ago
  No need to overthink it. In any semi-modern language you can (de)serialize anything to and from JSON, so it's really not that hard. The only thing you need to do is have a representation for the plan in your program. Which I will argue is probably the least error-prone way to implement --dry-run anyway (as opposed to sprinkling branches everywhere).
  - Jolter 9mo ago
    Right, but you still have to define every ”verb” your plan will have, their ”arguments”, etc. Not need to write a parser (even Java can serialize/deserialize stuff), as you say, but you have to meta-engineer the tool. Not just script a series of commands.

rook_line_sinkr 9mo ago

Dry run is great, but if you are using your script in a serious pipeline like that, you may want to go tho extra mile and write tests https://github.com/shellspec/shellspec https://github.com/shellspec/shellspec

spwa4 9mo ago

I would love to have this available in git. I know if you make mistakes you can use the reflog, but if you need 5 tries to get something right reading the reflog quickly becomes impossible. Plus there are operations, like rebase or merge, that feel the need to make 50 entries in the reflog. I've resorted to copying the entire directory (including the .git part) and then trying on the copy. The issue is that I'm working on a C++ program that has a few gigabytes of data.

joombaga 9mo ago
Consider using work trees. They have separate reflogs, you'd still get separate directories, but less duplication.

d7w 9mo ago

Funny, I recalled a tool called "molly-guard" which solves the problem when you want to reboot a Unix server, but can be on the wrong one. It asks to type the server name. Anybody who rebooted a wrong server can say that this tool is brilliant. Like "--dry-run" but for "reboot."

fainpul 9mo ago
These kind of obstacles don't work for any action that the user does repeatedly. Dialogs that pop up and ask "Are you sure you want to delete ...?" -> users just automatically click yes, because they already did that the last 10 times and just want to get on with their work. Logged in to server "alpha" instead of "delta" because you thought that's the right one. Tool asks you to write the server name. You type "alpha" because you know you're on alpha. Reboots the wrong server. Github ask you to confirm the repo name before deleting by typing it into a text field. User looks at what the repo name is and types it without thinking. Or, like lazy me, mark and drag the displayed name into the field, so you don't even have to type. The point is, users already decided to do the action when they started. It's nearly impossible to consistently make them stop and re-evaluate their decision, because that's extremely high friction and annoying. They quickly learn to circumvent the friction as efficiently as possible (i.e. without thinking about it). A better solution is to just do it, but let the user undo it if it was a mistake (not always possible of course).
- d7w 9mo ago
  > Or, like lazy me, mark and drag the displayed name into the field Yes, the same, unfortunately. This rail guard works for only a couple of days or weeks when the perception is fresh. After that, it's always "select, copy, paste, confirm" without thinking. I believe the better approach is to practice "Chaos Monkeys" and improve the infrastructure to survive even if someone makes a mistake.
- Mawr 9mo ago
  > Github ask you to confirm the repo name before deleting by typing it into a text field. User looks at what the repo name is and types it without thinking. Or, like lazy me, mark and drag the displayed name into the field, so you don't even have to type. Pretty easy to solve this sort of stuff with timers: "Sure, the repo will be deleted in <timer>. Press here to abort: <button>." Or have the timers on the backend and just show the user an undo button.

clawsyndicate 9mo ago

[dead]

Arbortheus 9mo ago

I prefer “—really-do”, so the default behaviour of the tool is to do nothing. That’s more fault tolerant for the scenario you forget to add “—dry-run”.

nvader 9mo ago
At a previous org, Boolean arguments could be toggled with the [no] prefix. The default for dry-run could be set to True, and then you had to type: ``` --nodry-run ``` Cut to, a new engineer asking me "Who is Nodry?"
- SoftTalker 9mo ago
  How about --i-might-lose-my-job-if-i-fuck-this-up ?

jaynate 9mo ago

> The downside is that the dryRun-flag pollutes the code a bit. In all the major phases, I need to check if the flag is set, and only print the action that will be taken, but not actually doing it. Sounds like a case for the state machine pattern

dabedee 9mo ago

From the article: "I added –dry-run on a whim early on in the project. I was surprised at how useful I found it to be." Not to be overly critical (I think it's great OP found value in adding and using --dry-run), but I am willing to bet that this was a suggestion/addition from a coding agent (and most likely Claude code/Opus). Having used it myself to build various CLI tools in different languages, it almost always creates that option when iterating on CLIs. To the point where it's almost a tell. I wonder if we're entering a moment of convergence where all the tools will have similar patterns/options because they are similarly written by agents.

SPBS 9mo ago
> Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option. > I remembered how helpful that was, so I decided to add it to my command as well. He mentions the reason he added it, and it's a compelling enough story to be true.
- dabedee 9mo ago
  Of course and I am not trying to point fingers. But I do think it's interesting because it's also possible that it is confabulation. Not lying, but genuinely constructing coherent explanations for decisions whose true origins are different than we recall. I think working with coding agents has already made this immensely more common.
  - mpyne 9mo ago
    I had the equivalent of --dry-run in my kdecvs-build script from 2003 (where it was called --pretend) so it's not that spontaneous an idea that it must have been dreamed up by an AI. Any time you have a script that needs to run for a long time or might involve destructive actions, having a way to run the script in a "tell me what you would do without actually doing it" mode is a fairly obvious user story to throw in.
    - 9mo ago

devcraft_ai 9mo ago

[flagged]

techpulse_x 9mo ago

[flagged]

nickjj 9mo ago

One thing that I didn't see mentioned is making your own dry run for tools that don't have it built in. It doesn't always work but sometimes I use `diff` to help with that. For example, if you have a complicated `sed` replacement that you plan to run on a file, you can use diff like this `diff -u <(echo "hello") <(echo "hello" | sed "s/hello/hi/g")` to help show what has changed. I've written about the value of dry run too at: https://nickjanetakis.com/blog/cli-tools-that-support-previews-dry-runs-or-non-destructive-actions https://nickjanetakis.com/blog/cli-tools-that-support-previe...

whalesalad 9mo ago

The fact that every single `--` has become — drives me bananas. For a technical blog this oversight is so sloppy.

terrabitz 9mo ago

A while ago when I was working with PowerShell a lot, I got spoiled by the easy inclusion of `-DryRun` flags in all my scripts. Nowadays I still use the technique for a lot of the tools I make. I typically do a Terraform-like approach: create a plan, validate the plan, render the plan to the user, exit early if we're in dry-run mode, and apply the plan as the final step. Whether dry-run is enabled by default depends on the risk of the operations and who will be using the tool. This makes it exceedingly clear what actions the tool will do. Plus it has the added benefit of being able to split the plan and apply steps into two separate steps. For example, you can create a plan, serialize it to JSON, store it (e.g. in VCS, Jira ticket, whatever) then apply it during a change window. plan = createPlan() print(plan.string()) if (dryRun){ return } plan.apply()

amelius 9mo ago

In even more praise of Ctrl+Z. (Don't try it in a terminal window, though)

deleted 9mo ago
[deleted]

mfonda 9mo ago

If the changes your command makes are strictly to a relational database, then `--dry-run` becomes quite easy to implement: just start a transaction and never commit it. This avoids polluting the entire command with `if dryRun` checks everywhere. I've found this to be a great approach.