Live data from Hacker News

Ooops.

github.com

151–160 of 247 posts

Re: Ooops.

#151
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.)

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…

I do that for 'rm'. I do an 'ls' first, then reedit the command and put an 'rm'.

Re: Ooops.

#152
post #142

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.

SQL is desperately in need of some updates. For starters, DELETE FROM should never be allowed without a WHERE clause. DBs should simply define that as malformed sql.

or at least interactive sql shells could ask you if you are really sure

Re: Ooops.

#153

Unix could really do with a command that you can wrap around this type of call. Either a sanity check on the path part or a safe rm alternative that contains it. I would gladly give up full rm access to know that I can safely (or safer-ly) delete in scripts. It could be something as simple as a file with paths on each line it - match one path or a path with a glob - and the script fails before destroying anything imp…

I sometimes use a wrapper around mv that moves the folder to trash. Guess it's not that portable but it could be replaced by moving to /tmp or something instead perhaps.

Re: Ooops.

#154
post #102

Looks like someone never read the Unix Hater's Handbook. Another fun thing is rm + shell expansion. A file named * or / can cause extremely unintended deletions.

that why you should add -- after your parameters to be extra safe

    rm -- -r -f  # removes files -r and -f

Re: Ooops.

#155

reminds me of http://thedailywtf.com/Articles/Bourne-Into-Oblivion.aspx

When you design something and the default case is to shoot yourself in the foot, you should stop and rethink things.

Re: Ooops.

#156
post #142

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.

SQL is desperately in need of some updates. For starters, DELETE FROM should never be allowed without a WHERE clause. DBs should simply define that as malformed sql.

Exactly. There is no need given TRUNCATE exists.

Re: Ooops.

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

For me it's not the stomach. First, breath stops, then for a few seconds numbness in chest and jaw, then face turns pale and soon red. A small nausea follows and then regret sets in. The rest of the day is ruined.

Re: Ooops.

#159
post #90

Earlier quoted context omitted.

Almost all of the desktop environments commonly used with Linux do have a trash bin.

If it wasn't obvious, "Why is `rm -rf` not connected to the recycle bin?" is implicit in my original question.

Good question. Here's my 60 second solution.
  alias rmmmmmmmmmmmmmmmmmmmmmm='rm -i'
  rm() { D="~/.Trash/`date +%s.%N`"; mkdir -p $D; mv "$@" $D; }

Re: Ooops.

#160
post #146

A decade ago, I worked on a DNA sequencer / aligner product. This produced easily 1GB+ raw data files, and they typically exploded by a factor of ten by the time you performed a bunch of cleaning, smoothing, filtering, etc on them. For several reasons, not least of which was a 4GB file size limit in fat32, this software had to use a directory as a pseudo file. I was working on some file saving logic. A customer had a…

It is crazy not to have backups of research data.
Post reply on HN