Hacker News Reader

Comment by js2 | Hacker News Reader

I learned a technique from a gray beard[0] when I worked as a student sys admin for the CS dept over two decades ago. Whenever typing a destructive command, he'd take his hands off the keyboard and drop them to his side, re-read the command, then put his hands back to press enter.

I do this whenever I'm on a production server (which is rare anyway). I use different colored prompts for local and remote shells.

[0] Technically he had no beard and if he had, it wouldn't have been gray.

View on HN

Re: Beards, color of:

Mine started turning grey in my mid 20s.

Could be related to me doing the electricians equivalent of deleting production DBs. I've drilled through the comms cable to payment terminals during opening hours. I've run over a copper gas line with a scissor lift. And yes, I've cut live 230V cables with hand tools.

That sinking feeling in your stomach you get immediately after doing something bad - it's universal across professions.

Thankfully, I've never fucked anything major up, and I've had my hands in hospitals, power plants, ISP fiber backbones, police stations and whatnot.

This reminds of a quote from, I think, Discworld.

> You're a survivor.

> But I've nearly died, dozens of times.

> Exactly.

Sounds like Rincewind. See also the octogenarian barbarians who are so deadly precisely because they've had a lifetime of experience of not dying.

That would be Cohen the Barbarian (aka Genghis Cohen) and his cohorts, collectively known as the Silver Horde.

> I've drilled through the comms cable to payment terminals during opening hours.

A friend of mine who does fire alarm systems was tasked to install one at a bank branch. He found out the hard way that one of the cables for the safes safety system wasn’t in the place where it should have been according to the plans. Safe’s safety system hosed, bank branch closed for repair.

Different-colored prompts for different machines is a great thing to do (I've been doing it for years), and very easy to implement

Solid tip. For GUI-enabled servers, use distinctively coloured wallpapers. I recommend bright red for production machines. The image itself can be just about anything, provided the colour is clear.

Doesn't hurt to use an image that's related to the server's purpose, and to put the name of the server right there in the wallpaper somewhere.

That's nifty, but sounds like more effort than changing a single color in one's .bash_profile

That's true, but depending on the configuration it may benefit all future users of the server.

Using iterm2, you can set a "badge" (large text overlay) on a terminal tab. I have a short shell function (`ib foo`) that sets the badge to arbitrary text. It's NOT as good as setting the terminal theme, but it's still very helpful to use it like this:

    ib production && ssh production-machine
    ib demo && ssh demo-machine

It's definitely helped me when testing a fix on a demo or staging instance, and has helped me avoid doing it on production accidentally.

Abel prompt that shows host name, username, and git branch

A similar tip I picked up long ago: If you're typing a dangerous command, first type a `#` (or `--` if it's SQL, etc.), then the command. Then read it. Then go back to the start of the line and remove the comment and run it.

A related Bash command: alt+# to prepend a hash symbol and submit the line, so you can return to it later (through Bash's history) to run it.

I always do destructive SQL commands in two steps: first run a select using the WHERE clause you intend to use and verify which records will be affected, then hit the up arrow and edit the beginning of the query leaving the WHERE intact.

I also like adding redundant conditions to the WHERE so a typo in any single one of them won't sink me.

For the rare but critical manual SQL mod our common safety measure is to wrap every DELETE or UPDATE in BEGIN TRAN...ROLLBACK TRAN first. Run on test systems or snapshots multiple times, checking the result inside the transaction.

Finally, change ROLLBACK to COMMIT only when you are positive all is well.

IIRC (without checking the manuals) data-definition commands might not be covered by such transactions: such as altering, dropping tables and possibly truncates.

PostgreSQL is quite good about DDL being transactional. So I was surprised (tbf, I shouldn't have been) when Redshift autocommitted after a TRUNCATE. But DROP TABLE is transactional, go figure.

DDL is transactional in Microsoft SQL Server as well.

I do the same thing. I also keep auto commit off and make sure the rows updated looks correct before committing the change.

For SQL, always BEGIN first. If you’re unsure, run it as an EXPLAIN first. Then fire. Then commit it or roll back.

I use an alternate version on SQL: when running any modification on any kind of sensible database (which is a bad practice in itself, obviously, but sometimes you don't have a choice), always type in the WHERE clause before the table name (added bonus: do a SELECT first with that clause to see what you are modifying).

That way, if you accidentally send it, the command fails and nothing happens.

Especially useful if you're remoted in over a laggy connection.

Reply on news.ycombinator.com