Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In praise of –dry-run

henrikwarne.com

Post reply on HN
Print view View original

121–130 of 175 posts

Re: In praise of –dry-run

#121

Post by dabedee »

SPBS wrote: post #120
dabedee wrote: post #119

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 c…

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

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.

Re: In praise of –dry-run

#124

Post by nickjj »

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 I've written about the value of dry run too at: https://nickjanetakis.com/blog/cli-tools-that-support-previe...

Re: In praise of –dry-run

#125

Post by mpyne »

dabedee wrote: post #121
SPBS wrote: post #120

Earlier quoted context omitted.

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

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.

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.

Re: In praise of –dry-run

#126

Post by d7w »

fainpul wrote: post #115
d7w wrote: post #109

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

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…

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

Re: In praise of –dry-run

#128

Post by dabedee »

mpyne wrote: post #125
dabedee wrote: post #121

Earlier quoted context omitted.

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.

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.

Again, it's completely possible that OP and you are the wonderful exceptions (untouched and uninspired by coding agents) that have been using these patterns for as long as you can remember. My comment revolved around the psychological phenomenon, not whether dry-run is a clever/novel idea. It's about how we might tell ourselves stories about the origin of our ideas when working with those tools.

Re: In praise of –dry-run

#129

Post by Mawr »

IgorPartola wrote: post #36
Twirrim wrote: post #28

Earlier quoted context omitted.

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

Uhuh:

    $ rm -rf /

    rm: it is dangerous to operate recursively on '/'
    rm: use --no-preserve-root to override this failsafe

Re: In praise of –dry-run

#130

Post by Mawr »

ronjakoi wrote: post #69
IgorPartola wrote: post #36

Earlier quoted context omitted.

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.

I used to have alias rm='rm -i' for a few years to be careful, but I took it out once I realised that I had just begun adding -f all the time

Yeah, but that's because it's implemented poorly. It literally asks you to confirm deletion of each file individually, even for thousands of files.

What it should do is generate a user-friendly overview of what's to be deleted, by grouping files together by some criteria, e.g. by directory, so you'd only need to confirm a few times regardless of how many files you want to delete.

Post reply on HN