Hacker News Reader

Comment by harikb | Hacker News Reader

I have a habit of creating cli tools, which potentially do dangerous things, to default to dry-run mode. For example, instead of the typical `--dry-run` or `-n` option, my scripts instead had a cheesy `--do-it` to be non-dry-run. It is annoying as hell to my colleagues, but saved the day many times.

View on HN

A coworker of mine would write all his bash scripts to echo out the commands it would run, and then to actually run it he would pipe it to bash. This way he could inspect the commands to make sure they were correct before running them.

Something like: ./dangerous-script.sh $args | bash

I also do this.

wow that's so clever and simple! Love it.

Is your coworker Willard Van Orman Quine?

I would love a shell that allows you to “run” a script in manual mode - Where at the end of every command, every statement, it prints what the next command will be with all variables expanded or otherwise called out, and then requires you to hit “enter” to cause it to proceed. I write a decent amount something between README and Shell Script. I’ve already got an awk one-liner that parses the shell out of Markdown. I typically copy+paste, line-by-line, from my README and add a bunch of echo statements to verify what i’m doing.

Press f8 to process autoexec?

Same, or save to a file, temporarily, check that, then run the resulting script.

In PowerShell, this is a native feature of the entire shell and hence scripts and commands.

The following prefix in a ps1 script enables the -WhatIf and -Confirm parameters:

    [CmdletBinding(SupportsShouldProcess=$true)]

To enable -Confirm by default for scary scripts, just use:

    [CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact='High')]

The nice thing is that in PowerShell, unlike bash, this flows through to the vast majority of other commands. If the script has the snippet above, then you don't have to litter it with "if ( $userSaidYes ) { ... }" blocks all over the place.

Similarly, PowerShell automatically wires up logic to produce all of the useful modes you might want:

    [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend

This is very fiddly to implement manually, and "Suspend" is likely impossible for most shells.

See: https://docs.microsoft.com/en-us/powershell/scripting/learn/...

I did this with "--im-not-scared" for production mode :D

We had one that required "BADIDEA" to run

I do something similar with my scripts, but have `--go` action, even on a script that requires no other options, just so that if it's run without any options, the person running it gets a message saying what the script WOULD do, if `--go` were passed in.

I do the same thing. All of my scripts have a -defang parameter which walks through the entire process, including placeholder log messages, but not actually performing the operation. My run books always say to run your exact command with this switch first, to proofread it. For some dangerous scripts, defang is enabled and has to be manually turned off. Defang is also nice because it will tell you e.g. here’s the size of the backup you’ll be restoring, or the filepath you’ve composed based on your parameters, or confirming that you’ll be replacing an existing thing instead of creating a new one. It has saved me many, many times.

Bash tip I picked up from observation - always start a potential command with #

# rm -rf some_dir

Then if you accidentally press return before completing it hasn't happened.

When you have reviewed and are sure it is correct, you recall and delete the hash to execute - simples!

Does this work with autocomplete?

Just tried it with bash on Linux, and apparently autocomplete works in a comment.

In my opinion, the option -r should only be allowed as the last parameter. Maybe with the exception of -f. Everything else is just f*ing dangerous.

I mean, I use the # hack sometimes too, but when I don't, I find myself often being afraid of accidentally coming on the enter key.

I generally throw up a status report type of thing "you are applying $this_operation to $this_many_machines on $this_farm. Continue (yes/no)?" and enforce yes/no full typing. Anything other than yes is a no

Even having a dry run mode is exciting. Doesn't even have to give complete results just "I was planning to delete 3 files and create 7 files", gives a hint whether the command will blow up the system or not.

I wish SQL had a dry-run mode in updates and deletes for that reason.

"Run it as a query first" gets 90% of the way until you drop a constraint by accident whilst rewriting it as an update :o

For interactive queries / surgery, you do have an option with a transaction (begin/commit/abort).

If it is Postgres (don't know about other dbs), you can go a way long way using "savepoints" and "rollbacks" to truly have a trial-and-error safe surgery on db. Still dangerous, but quite helpful. I hate working on any other db without those features. Postgres also allows schema changes to be within a txn envelope.

Transactions and rollback is the dry run. The problem is that if you keep the transaction open for too long, you will block other updates to the same data.

Yep, I always write any update queries as a rollback transaction with some selects inside it to verify what the data looks like after it's done now, before I switch it to commit. I primarily use Microsoft SQL Server right now, so I also use WITH (NOLOCK) to prevent issues running my query will have with other updates.

Wrap it in a transaction and roll back the transaction at the end. Then remove the transaction when you are ready to do it for real.

You can jam a select in the end of the transaction to check what happens.

I've thought the same thing. I also wish SET came after where. I've done "UPDATE table_x SET something = true"; and then forgot the WHERE clause.

I think an improvement to SQL would be for insert/update/delete clauses to require a where clause and allow for something like 1=1 if you really intend to hit all rows. A safe but even more invasive would be requiring an end to the were clause as well (to prevent selecting a few but not all constraints).

I think this is true for mysql, at least for delete.

MySQL has a command line option "--i-am-a-dummy" (aka "--safe-updates") for exactly this purpose.

https://dev.mysql.com/doc/refman/8.0/en/mysql-command-option...

Enough folks have replied that transactions are the way to go, but I just wanted to add that whatever interface tool you use for your database may have an option to force you to commit your transactions manually. For example PostgreSQL's default 'psql' shell has the "autocommit" option which, when disabled, requires you to manually 'commit;' before any changes take effect.

I like this format in general, since it communicates the command is severe/irreversible. Heroku implements a similar confirmation when performing destructive actions. Commands require your to pass a `--confirm ${APP NAME}` flag, so the original command itself does nothing. Of course, this doesn't prevent you including those flags in makefiles, etc. I once dropped a table in a side project by accident because I took the wrong tab autocomplete suggestion in a makefile.

works great until some asshole puts

  alias harikb_script='harikb_script --do-it'

in their .bashrc to eliminate this annoying step.

This would help a bit: Don't accept the "--do-it" as first parameter, make it obligatory to be the last.

  my_command() {
      command my_command "$@" --do-it
  }

Good point. Stuff like this is why I wrote "a bit". Thank you for providing an example, why it wont be enough.

If someone is a programmer and is trying to disable safety features making it slightly harder to do so doesn't really seem like the solution.

I suspect someone who'd do that isn't going to take that or other precautions seriously regardless of it being aliased. It's still a problem that they're circumventing it, but I think you have a larger problem if someone with that mindset has access to production.

We've been known to use something like --yes-i-really-mean-it-this-time for really dangerous options. It's a like built-in solemnisation step.

I once came across one like this

$ run-script.sh --dry run

`--dry-run` parameter not recognized

Executing ...

Reply on news.ycombinator.com