6 ms·
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'
by js2 6y ago
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.
- brundolf 6y agoDifferent-colored prompts for different machines is a great thing to do (I've been doing it for years), and very easy to implement
- MaxBarraclough 6y agoSolid 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.
- brundolf 6y agoThat's nifty, but sounds like more effort than changing a single color in one's .bash_profile
- MaxBarraclough 6y agoThat's true, but depending on the configuration it may benefit all future users of the server.
- gknoy 6y agoUsing 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.
- TylerE 6y agoAbel prompt that shows host name, username, and git branch
- encom 6y agoRe: 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.
- MaxBarraclough 6y agoThis reminds of a quote from, I think, Discworld. > You're a survivor. > But I've nearly died, dozens of times. > Exactly.
- andreareina 6y agoSounds like Rincewind. See also the octogenarian barbarians who are so deadly precisely because they've had a lifetime of experience of not dying.
- mangamadaiyan 6y agoThat would be Cohen the Barbarian (aka Genghis Cohen) and his cohorts, collectively known as the Silver Horde.
- Xylakant 6y ago> 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.
- morelisp 6y agoA 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.
- MaxBarraclough 6y agoA 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.
- grossvogel 6y agoI 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.
- tatersolid 6y agoFor 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.
- mjevans 6y agoIIRC (without checking the manuals) data-definition commands might not be covered by such transactions: such as altering, dropping tables and possibly truncates.
- andreareina 6y agoPostgreSQL 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.