Live data from Hacker News

In praise of –dry-run

henrikwarne.com

61–70 of 175 posts

Re: In praise of –dry-run

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

Just don’t randomly mix and match the approaches or you are in for a bad time.

Re: In praise of –dry-run

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

There was a tool I used some time ago that required typing in a word or phrase to acknowledge that you know it's doing the run for real.

Pros and cons to each but I did like that because it was much more difficult to fat finger or absentmindedly use the wrong parameter.

Re: In praise of –dry-run

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

Re: In praise of –dry-run

#66
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 have a parallel directory deduper that uses hard links and adopted this pattern exactly.

By default it'll only tell you which files are identical between the two parallel directory structures.

If you want it to actually replace the files with hard links, you have to use the --execute flag.

Re: In praise of –dry-run

#67
post #35
post #7

Earlier quoted context omitted.

this is where design patterns come in handy even tho folks roll their eyes at it.

Design patterns are one of those things where you have to go through the full cycle to really use it effectively. It goes through the stages: no patterns. -> Everything must follow the gang of four's patterns!!!! -> omg I can't read code anymore I'm just looking at factories. No more patterns!!! -> Patterns are useful as a response to very specific contexts. I remember being religious about strategy patterns on an ap…

What about the productivity gains from in memory db for tests though? Hard to measure I guess

Re: In praise of –dry-run

#68
post #32

Earlier quoted context omitted.

I've done that, but I hate the term "wet run." I use "live run" now, which I think gets the point across without being sort of uncomfortable.

--with-danger --make-it-so --do-the-thing --go-nuts --safety-off So many fun options.

It's in the UI not the command line, but I like Chromium's thisisunsafe

Re: In praise of –dry-run

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

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

Re: In praise of –dry-run

#70
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.
Post reply on HN