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

Ooops.

github.com

Post reply on HN
Print view View original

91–100 of 247 posts

Re: Ooops.

#91

Post by praeclarum »

shrikant wrote: post #44

Perhaps because I'm not a GitHub user, and because I've only ever peeked at HNers' GitHub accounts, but I was always under the impression that given the nature of the service, it would have an early-days-of-HN feel wrt to user behaviour. It was a little disheartening to see the number of Reddit-esque comments that are simply a couple of words along the lines of "omfg" and a constant stream of meme abuse. I expected b…

You're not too much of an elitist, you're too much of a crank. Does it really dishearten you to see a bunch of people having a good laugh? Does every word written on the internet need to be researched/profound to be worthy of reading? This is the internet, it will forever dishearten you if you think in these terms.

Re: Ooops.

#92

Post by rimantas »

MatthewPhillips wrote: post #75
crikli wrote: post #65

The reason we all know to be careful with rm -r is because of that one time we weren't. Me, it was the time I rm r'ed the MySQL data directory for my company's customer service management system. Oops. Thankfully we had a backup from the month prior, but I learned two things that day: a) be really careful with rm and b) take it on yourself to make sure IT is backing up stuff that you're messing with. You gotta hedge…

More than once I've made the mistake of running an UPDATE and forgetting the WHERE clause.

In case you are using MySQL this can be handy: http://dev.mysql.com/doc/refman/5.5/en/mysql-command-options...

Re: Ooops.

#93

Post by RyanMcGreal »

trafficlight wrote: post #76
srean wrote: post #46

I learned a rather unusual trick to keep myself safe from unintended glob matches. It is not "fool"-proof, but it will probably dilute an unmitigated disaster into an incomplete disaster: Keep a file named -i in the sensitive directories. When glob picks it up, which should be fairly early, it will be treated like a command line argument. Has saved me on occasions. I also had a friend in school who used to, for whate…

I hate that feeling you get in the pit of your stomach after you realize what's happening. Same thing when you forget the WHERE on a DELETE FROM.

I made that mistake once. My DBA never let me live it down.

Thank goodness for daily backups.

Re: Ooops.

#94

Post by nuclear_eclipse »

stephen_g wrote: post #39
nuclear_eclipse wrote: post #30

Earlier quoted context omitted.

and the entire windows directory, and the entire users directory, and ...

It was only deleting /usr, which doesn't contain home directories or config files. I suppose that /usr does store a good chunk of what the Windows directory has in it though.

Sorry, was thinking of the awful `rm -rf /` variant...

Re: Ooops.

#95

Post by strickjb9 »

jerf wrote: post #84
trafficlight wrote: post #76

Earlier quoted context omitted.

I hate that feeling you get in the pit of your stomach after you realize what's happening. Same thing when you forget the WHERE on a DELETE FROM.

Over the years I've been steadily training myself to type "WHERE" earlier in the process, until I have finally settled on the obvious-in-hindsight solution: Always simply start with the WHERE clause. (Of course every effort not to be on the SQL shell of a production server in the first place should be taken, but sometimes you need a sledgehammer and nothing else will work.)

Same - I now write DELETE FROM WHERE and then fill in the blanks.

Re: Ooops.

#96

Post by moheeb »

trafficlight wrote: post #85
jerf wrote: post #84

Earlier quoted context omitted.

Over the years I've been steadily training myself to type "WHERE" earlier in the process, until I have finally settled on the obvious-in-hindsight solution: Always simply start with the WHERE clause. (Of course every effort not to be on the SQL shell of a production server in the first place should be taken, but sometimes you need a sledgehammer and nothing else will work.)

I do that now, too. I have a trigger-happy semicolon finger.

My method is to write each DELETE as a SELECT first. This has the benefit of actually verifying the DELETE you were about to write.

Re: Ooops.

#97

Post by samstokes »

jerf wrote: post #84
trafficlight wrote: post #76

Earlier quoted context omitted.

I hate that feeling you get in the pit of your stomach after you realize what's happening. Same thing when you forget the WHERE on a DELETE FROM.

Over the years I've been steadily training myself to type "WHERE" earlier in the process, until I have finally settled on the obvious-in-hindsight solution: Always simply start with the WHERE clause. (Of course every effort not to be on the SQL shell of a production server in the first place should be taken, but sometimes you need a sledgehammer and nothing else will work.)

The habit I learned was: before running any DELETE or UPDATE statement, run a SELECT with the same WHERE. (e.g. if I meant to say DELETE FROM puppies WHERE cute = 0, first run SELECT FROM puppies WHERE cute = 0.)

I find I remember to do that because of the direct benefit (getting a sneak preview of what I'm going to delete), but it also means I end up thinking twice about the WHERE statement, so I'm much less likely to miss it out or get it dramatically wrong.

Re: Ooops.

#98

Post by blhack »

trafficlight wrote: post #76
srean wrote: post #46

I learned a rather unusual trick to keep myself safe from unintended glob matches. It is not "fool"-proof, but it will probably dilute an unmitigated disaster into an incomplete disaster: Keep a file named -i in the sensitive directories. When glob picks it up, which should be fairly early, it will be treated like a command line argument. Has saved me on occasions. I also had a friend in school who used to, for whate…

I hate that feeling you get in the pit of your stomach after you realize what's happening. Same thing when you forget the WHERE on a DELETE FROM.

I wish there was a way to put a limit on table updates in mysql's config file.

"Only let me update 5 rows at a time." or somesuch.

I now usually type the command out-of-order.

So I'll type:

where user_id = $f00 limit 10;

then prepend the "update foo set bar = " to it...

Re: Ooops.

#100

Post by CGamesPlay »

illumin8 wrote: post #71
crikli wrote: post #65

The reason we all know to be careful with rm -r is because of that one time we weren't. Me, it was the time I rm r'ed the MySQL data directory for my company's customer service management system. Oops. Thankfully we had a backup from the month prior, but I learned two things that day: a) be really careful with rm and b) take it on yourself to make sure IT is backing up stuff that you're messing with. You gotta hedge…

Was asked to uninstall IBM/Rational ClearCase from our source code repository server. Apparently at the time, Clearcase's installer NFS mounted 127.0.0.1:/ to a subdirectory. Don't ask me what brain-dead system designer thought this was a good idea. So, I did a simple /etc/init.d/clearcase stop (not sure that is the exact name) and: # rm -rf /opt/clearcase (hmm... that seems to be taking a little too long to run) Pan…

I've also done this, but it was a cPanel server and the jailshell did bind mounts to various directories on the system. I tried to remove the jailshell instance, and ended up removing a whole lot more.
Post reply on HN