• (cs) in reply to Anonymouse
    Anonymouse:
    akatherder:
    He never should have run the script. But the script should have been deleted and he should not have access to the script in "production" either.

    No, the code used to create the database could prove useful as a reference later, and you might even want to run it as it is to create a second database. Throwing it away would be dumb.

    Maybe you aren't familiar with SQL, but the command to CREATE a database is completely separate from the command to DROP one. While it could prove useful to retain the CREATE command to make a clone of the database, there's no value in archiving 'DROP DATABASE database_name'.

    1. It's trivial to remember or to look up,
    2. it contains no useful information (whereas the CREATE command hold the default structure of when it was built),
    3. and it's very dangerous.
  • BleuCollarAstronaut (unregistered) in reply to Bluemoon

    The spelling is wrong, and the moon isn't blue.

  • Ant (unregistered) in reply to DaveAronson

    Do NOT hit the big red button

  • (cs)

    I can't fathom what was going through the newbie's mind... "well, I ran this script and now everyone's shouting at me. I think I'll just run it again a few more times and see what happens..."

  • Matt (unregistered)

    In other news, work progresses smoothly on the big, red, "Please do not push the big red button", button.

  • Matt (unregistered) in reply to Matt

    Darn you Ant!

  • (cs) in reply to Stiggy
    Stiggy:
    DO NOT EVER READ THIS COMMENT
    Crap! I screwed up! Is there a workaround for any side effects I may experience?
    rockfrog:
    The comment could have been clearer... "re-creates the database" might be interpreted as "restores the database". Should have read "creates a new empty database".
    This is actually a reasonably good point. The guy is still dumb, but it's not *quite* as clear cut as it first seems. I do think the natural interpretation is to create a new one, but I could see someone interpreting it that way.
  • (cs)

    I'm trying to get my head around the exact pathology of the guy.

    He understands how to change permissions on a file. He understands (sort of) ksh scripts (or at least how to delete "exit 1").

    He doesn't understand plain English in block capitals. He doesn't understand sql (fair enough, but c'mon ... "drop table?").

    Most of his synapses appear to be fried. Exactly what would he have been looking for, after running the script, to "see how it worked?"

  • (cs)

    He should have added a mail(); call that mailed him and [email protected] with the name of the person who ran the script saying "This guy just destroyed everything after we asked him not to"

  • (cs) in reply to real_aardvark
    real_aardvark:
    I'm trying to get my head around the exact pathology of the guy.

    He understands how to change permissions on a file. He understands (sort of) ksh scripts (or at least how to delete "exit 1").

    He doesn't understand plain English in block capitals. He doesn't understand sql (fair enough, but c'mon ... "drop table?").

    Most of his synapses appear to be fried. Exactly what would he have been looking for, after running the script, to "see how it worked?"

    The only logical answer is that he understood "Re-create the database" as re-creating the database and all the data rather than a blank db.

  • Donald Duck (unregistered) in reply to Paul
    Paul:
    2. Obviously this ran on a *NIX system, so ... why wasn't ownership of the script set to a user with a password that only experienced programmers knew, so that it couldn't be made executable ... or, don't tell me, did everyone know the root password? I'll bet it was written on a post it note on the box running the db.

    cat cant_run_this_script > newscript

    chmod +x newscript

    Wouldn't have made a difference.

  • Nutmeg Programmer (unregistered)

    There should be a class of error called a Chernoble error. To make a Chernoble error, you first defeat all features designed to prevent catastrophe. Then proceed to test... the catastrophe.

  • Bob N Freely (unregistered) in reply to Er..um
    Er..um:
    I worked for a broker than used a spreadsheet as a way of distributing summaries of research - so everytime you wanted to look at the summary info on one company, you had to open the entire spreadsheet (A Sizeable VBA app) on your PC. It also meant only one person could update it at a time, which meant it was usually out of date.

    One of my first jobs in IT/software was working for a trade organization that handled a group insurance plan for their members. When I started (in the early 90's) they were keeping each member company's employee data in a Lotus 1-2-3 spreadsheet with a bunch of lookup tables to figure out the premiums. A separate file for each company. Every time the insurance provider changed premiums (about twice a year), we had to go in and change the values in the lookup tables on every single file. That's what they initially hired me to do, because they'd heard I was "good with computers." It was workable when they only had 20 or so companies to deal with. But shortly after I started, they expanded the program and soon had over 100 member companies.

    It quickly became obvious that the spreadsheet solution wasn't going to work anymore. I convinced them to move to a database solution. But I was very inexperienced (I had just finished my first year of college, majoring in Biochemistry, and had only had a single programming course). I wound up doing the whole thing in Access 2.0, and had to pretty much teach myself relational databases from the ground up. The employees were all kept in a table, with the employers and premium amounts in separate tables. So when premiums had to be changed, we only had to do it in a single place. I set up forms for doing things like adding or editing employees or companies. The premium bills were a set of reports, one for each company, and I set up a macro that would print them all off with the click of a single button. It was infinitely better than the spreadsheet solution, but looking back, I can think of about 50 things I did totally wrong. Still, they were so happy, they made me a full time employee (when I was home during summer and holidays) and gave me a big raise. Plus, if they had to call me at school to troubleshoot something, they'd pay me for the extra time. That job was riddled with WTFs, but it kept me in pizza and text book money for 3 years.

  • dzb (unregistered)

    The real wtf is clearly letting a newbie having sufficient access rights to destroy production data.

  • joe (unregistered) in reply to PSWorx

    He NEVER read terry pratchett? If you label a door "Do not enter here, ever, seriosuly, you WILL die", the first thing a wizard will do is to enter the door, just to see what is on the other side.

  • critosopher (unregistered)

    What kind of genius makes highly destructive scripts which should never be run, and worse yet, can be modified and run by the ignorant? Layoff "farewell" code, perhaps? Might as well make that rm -fr script next.

  • Lawrence (unregistered) in reply to PSWorx

    Sure, if we were kids in high-school... but come on! We're supposed to be professionals in a business! I think it's beyond time for the IT industry as a whole to grow up a little and act like adults instead of teenagers (or younger).

    That's not say don't enjoy your job, or have fun, etc. But do it as an adult, please!

  • (cs)

    So if you see a sign that says "Wet paint" and you touch it and get paint all over your hands, the solution is to touch the wet paint over and over again to see if you can get the paint off. Brilliant!

  • Timwi (unregistered)

    I can only repeat what some people have already said. Of course the newbie shouldn't have run the script, but the author also shouldn't have kept the script around for anyone to run, much less configured to access the production data. Putting "Don't run this script" at the top is equivalent to saying "I'm too dumb to delete this script".

  • Franz Kafka (unregistered) in reply to rockfrog
    rockfrog:
    The comment could have been clearer... "re-creates the database" might be interpreted as "restores the database". Should have read "creates a new empty database".

    Sure, if you're a moron, which the newbie was.

    Paul:
    1. Why keep a script around that shouldn't be run? (Yes, you may actually NEED to rebuild the db sometime, but the installer scripts could have been kept in a separate area of the repository with limited read-access.)

    or just don't let the noob developer have delete access on a production database.

    2. Obviously this ran on a *NIX system, so ... why wasn't ownership of the script set to a user with a password that only experienced programmers knew, so that it couldn't be made executable ... or, don't tell me, did everyone know the root password? I'll bet it was written on a post it note on the box running the db.
    because it was in source control.
  • ChiefCrazyTalk (unregistered) in reply to pitchingchris
    pitchingchris:
    Newbie was really dumb. He really needed to see what it did, especially since it told you "DO NOT EVER RUN THIS SCRIPT - IT DESTROYS, THEN RE-CREATES THE DATABASE". It told you right then and there what it did.

    Kind of like that old saying of trying the same thing expecting different results.

    I don't see the problem. Sure, it destroys the database but then it recreates it. Sounds perfectly safe to run to me!

  • Franz Kafka (unregistered) in reply to James
    James:
    If it should not ever be run . . . just delete it.

    Never delete anything that could possibly be useful. Also, don't hire idjits to write your code.

  • Franz Kafka (unregistered) in reply to James
    James:
    If it should not ever be run . . . just delete it.

    Never delete anything that could possibly be useful. Also, don't hire idjits to write your code.

  • Franz Kafka (unregistered) in reply to James
    James:
    If it should not ever be run . . . just delete it.

    Never delete anything that could possibly be useful. Also, don't hire idjits to write your code.

  • Ben (unregistered)

    Whoever suggested removing the DROP command from the script so that the CREATE fails and exits gracefully....

    This n00b has already shown he would stop at nothing to run this script. After getting the database error "table already exists", what do you think he would do?

    1. If the file isn't runnable --> change it so it's runnable
    2. If the script shouldn't be run --> run it
    3. If the table already exists --> manually DROP it

    Sure, the script shouldn't have been there in the first place, but this guy was a very determined tinkerer, and he really is the WTF.

  • (cs) in reply to N
    N:
    I'm always amused when people explain the ethernet and routing using cars. Imagine an intersection randomly picking cars and smashing them to react to traffic jams.

    If the metaphor was perfect, it wouldn't be a metaphor. For some purposes, using a car metaphor may be appropriate, if cars share the relevant characteristics. For other purposes, it wouldn't make any sense.

  • Not_a_moron (unregistered)

    You are a moron for leaving the script out there. Of course someone is going to run.... If not some newbie, then someone may disgruntled employee will...

    You should be held just as responsible as the newbies.

  • Hans (unregistered) in reply to John
    John:
    DO NOT EVER REPLY TO THIS COMMENT EVER, OR ELSE IT WILL COMPLETELY RECREATE THIS WEB SITE!

    You should have told Alex about that before he replied to it last week... Who knows how long it will be before he can reset all the colors to their normal sane values?

  • raz (unregistered)

    Well, I have to support the view that writing that the script "RE-CREATES" the database is at fault here.

    The script doesn't. It just RE-CREATES the empty structure, NOT the data.

    Of course this is normal procedure for people experienced with databases, but I would NEVER EVER write this to any non-professional out there. They would ALL assume that RE-CREATE will both include STRUCTURE as well as DATA.

    Why didn't you dump the data in a file in the script BEFORE dropping anyway?

    For me that's standard procedure in such a script.

  • DHager (unregistered) in reply to tray
    tray:
    This would make a standard test procedure for newbies. Give him a job with a faked system and a script like this, and if he doesn't run the script in a week, he would be invited in the next round.
    But you also need to test that they looked at it, so that you test for dangerous-monkey-tinkering as well as no-curiosity-laziness.

    Everyone dealing with new employees in the tech field must understand the Tao of the man with the Yellow Hat: "Until you have learned, looking is a virtue, touching is a vice."

    akatherder:
    But the script should have been deleted [...]
    It was probably the living-documentation reference for how to recreate the database structure fresh--you don't throw that kind of thing away.
  • mfg (unregistered) in reply to notromda
    The REAL wtf is cold fusion and ksh...

    Why? Allaire Cold Fusion started life as a pretty decent application server. It ran on Solaris with version 3.1 when they figured out it could be a serious production tool.

    Oh and what a revolution, a mere junior developer can embed presentation logic right in the presentation layer! Of course, the inevitable happens when you let THEM write procedural logic into a declarative file. Spaghetti.

  • (cs)

    Noobs clearly disown.

  • (cs) in reply to whicker
    whicker:
    (Car analogies always apply to software)
    Syntax error.
    (car '(analogies always apply to software))
  • disord3r (unregistered)

    Seems to me, creating a script

    1. whose purpose is to drop/recreate a database without backing it up first
    2. not taking proper steps to ensure that it can't be run by the adventurous or 'unskilled labor'
    3. not clearly detailing in the comments the consequences of not heeding the warning

    was kinda asking for trouble. :)

  • morry (unregistered)

    I've always thought it's better to put these things into the positive, i.e. don't use "don't". For example:

    RUN THIS SCRIPT WHEN YOU WANT TO BE FIRED

    EXECUTE THIS PROGRAM WHEN LIFE NO LONGER HAS MEANING FOR YOU

    IF YOU LIKE EVERYONE HATING YOU, THEN START THIS JOB

    MAKING TOO MUCH MONEY? DO THIS TO REDUCE YOUR PAYCHECK TO 0!

    GET ESCORTED OUT BY MERELY PUSHING THIS SHINY RED BUTTON

  • Thierry (unregistered)

    Maybe I'm missing something but :

    • script is KSH
    • commands to destroy the database are SQL

    How can one run SQL commands directly from a ksh script ? That story might be fun, but as far as I'm concerned, it's total BS.

    (but... if scripts contains something like : ( ** SQL COMMANDS HERE ** ) | isql command with log+password

    this, might work.

  • (cs)

    I folks, I'm the submitter of this one...

    As I said in the post, it was only intended to be a teach-myself-how-to-do-something-non-trivial-in-CF system, intended to be thrown away.

    There was no actual production db; just the one in the development db server. As for keeping the script around, it was in a doc's folder, which had a _README.txt file at the top of the directory listing clearly spelling out what each file/directory in the system did. There were 3 paragraphs dedicated to this script.

    The guy who took over for me had 8 years of "professional" experience and seemed rather intelligent, at least conversationally.

    Addendum: after he trashed this system, my boss transferred him to another department, where he went on to trash a real prod db, with lots of transaction data in it. For that one, he was fired.

  • Russ (unregistered) in reply to notromda
    notromda:
    The REAL wtf is cold fusion and ksh...

    Seriously - Who in their right minds runs a program (on a live system) to see what it does? Read the code!

    The real wtf is that you can't spell ColdFusion. That one never gets old.

    Seriously though, I'm surprised you guys aren't bashing CF more here. I though it was a favourite past time around here.

    Seriously though, CF is cross platform, and is a great product. Unlike lets says ASP, or .NET it runs natively on Windows, Linux, Macs, etc. I believe it's even certified on 64bit solaris.

  • (cs) in reply to Thierry
    Thierry:
    Maybe I'm missing something but : - script is KSH - commands to destroy the database are SQL

    How can one run SQL commands directly from a ksh script ? That story might be fun, but as far as I'm concerned, it's total BS.

    (but... if scripts contains something like : ( ** SQL COMMANDS HERE ** ) | isql command with log+password

    this, might work.

    The posted script is just paraphrased. The read script did the sql work in a here-document something like this:

    #!/bin/ksh echo ... isql -u username -p password -s server <<EOF drop ... create ... commit quit EOF

  • dood (unregistered)

    I never leave comment like that any more. Come back a year later and I wouldn't even know what I wrote. Way better to say 'THIS SCRIPT DROPS THEN RE-CREATES THE TICKETS DATABASE. ALL DATA WILL BE LOST'

    I've been in the newbie's position before, but in my case I commented out all the sql execute commands and instead printed them to the screen.

    a WTF on both sides, in this case.

  • and why is the script there? (unregistered) in reply to PSWorx

    So if the script is never supposed to be run, what is it doing on the filesystem? Delete the damn thing. If you need it, for future reference, it's (presumedly) in version control.

  • (cs) in reply to snoofle
    snoofle:
    Addendum: after he trashed this system, my boss transferred him to another department, where he went on to trash a *real* prod db, with lots of transaction data in it. For that one, he was fired.

    While it makes US feel better to hear that, the real problem is that HE was probably still totally clueless. He's probably sulking about how he was "unfairly dismissed" and "did nothing wrong".

    Reminds me of a comedian I saw once. He said "You know how in every family there's always that one dumb one? ... and if you're sitting there thinking, 'wait, no, my brother's not dumb' -- guess what? It's YOU!"

  • Barf 4 eva (unregistered) in reply to snoofle
    snoofle:
    I folks, I'm the submitter of this one...

    As I said in the post, it was only intended to be a teach-myself-how-to-do-something-non-trivial-in-CF system, intended to be thrown away.

    There was no actual production db; just the one in the development db server. As for keeping the script around, it was in a doc's folder, which had a _README.txt file at the top of the directory listing clearly spelling out what each file/directory in the system did. There were 3 paragraphs dedicated to this script.

    The guy who took over for me had 8 years of "professional" experience and seemed rather intelligent, at least conversationally.

    Addendum: after he trashed this system, my boss transferred him to another department, where he went on to trash a real prod db, with lots of transaction data in it. For that one, he was fired.

    well holy shit... The man is given a second chance and is shown the errors of his ways via the dev db, only to get put on another project and thrash the prod db?? I think your company made the right decision in firing him.

    But still...... you mean to tell me after everyone had the luxury of knowing how much of a renegade jackass this guy was, he was STILL given full permission to a production server in the other dept?!?? :P

    Well, either your boss didn't communicate the problem effectively, or the other department didn't really heed your boss's warnings about said noobie. In which case, someone else is still at fault, imo.

  • Franz Kafka (unregistered) in reply to snoofle
    snoofle:
    There was no actual production db; just the one in the development db server.

    Disagree. Once it's used for real business and tracking prod issues, it's a production DB.

  • Bhaarat (unregistered) in reply to morry

    WTF!

    was a n00b given admin rights to all the files?? shouldnt this type of script be under admin rights only? how was he able to change permissions on such a file. WTF ind33d

  • Yekvin (unregistered)

    Oh, how long can trusty Cadet Stimpy hold out? How can he possibly resist the diabolical urge to push the button that could erase his very existence? Will his tortured mind give in to its uncontrollable desires? Can he resist the temptation to push the button that, even now, beckons him even closer? Will he succumb to the maddening urge to eradicate history? At the MERE...PUSH...of a SINGLE...BUTTON! The beeyootiful SHINY button! The jolly CANDY-LIKE button! Will he hold out, folks? CAN he hold out?

  • Anonymoose (unregistered) in reply to n9ds

    I think you meant "Brillant!".

  • awfafawfw (unregistered)

    Should've taken a different tact:

    "THIS SCRIPT DOES NOTHING. THAT'S RIGHT, NOTHING. SEE ALL THOSE DROP STATEMENTS? THEY DO NOTHING. IN FACT, I DARE YOU TO RUN THIS SCRIPT. I DOUBLE DARE YOU, WITH A CHERRY ON TOP. ONLY REAL MEN RUN THIS SCRIPT THAT DOES NOTHING. ARE YOU A REAL MAN?"

  • keebler (unregistered)
    Terry Pratchett:
    Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying "End-of-the-World Switch, PLEASE DO NOT TOUCH," the paint wouldn't even have time to dry.
  • anonyMouse (unregistered) in reply to morry

    I agree with poster #1. Just wondering why the heck he let a "newbie" touch code on production?! Any decent place I've worked does not allow that type of access to a newbie; trust is earned, not free.

Leave a comment on “Do not run this script, ever!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article