I don't generally keep scripts like that around where people can run them and if I must I change #!/bin/ksh to something else like #!/bin/cat.
If I actually had to worry about working with someone like the guy in the article, I'd go further and create my own "shell" that would pretend to run the commands but would otherwise syslog/page me whenever someone actually ran it.
The newbie of this story jumped through two hoops to run the script "to find out what it does". He would surely jump through the hoop of changing it to a working shell as well.
Obvious only in retrospect would be to remove the "DROP TABLE" commands. Those contain no useful information worth keeping around -- the CREATE TABLE commands do.
Of course, the best and most general solution is exactly what he did: Keep backups and logs sufficient to rebuild everything up to the moment it was ruined. That will save his neck again someday, for a completely unrelated reason.
We actually encrypted the code of dangerous tools (we wrote in Perl back then) like this one with a password so the customers (telecoms) tech people, who were mostly clueless, wouldn't be able to play around with our tools.
The program was just a tiny bit of code describing the tool, prompting for a password, tried to decrypt the code of the original program using the password and evaled the code.
Interesting idea. You would think the database user/password and a few grant/revoke statements would be sufficient to prevent issues like the one in the article.
If the author really meant "do not ever run this script", he should have deleted it. Instead, he added a comment. When comments disagree with code, code wins. Rather than taking responsibility and learning this, he blames the stupidity of a newbie.
It's useful to have those scripts around, you might want to do another installation somewhere or it might just be useful to see how the tables are meant to be if they get screwed up.
Well, sure. But then he didn't really mean what the comment said, which was "DO NOT EVER RUN THIS SCRIPT". There are any number of strategies he could have used to prevent what happened. The one he chose was to add an inaccurate comment to code and assume that every subsequent programmer would read it, understand its meaning, and do what it said. That's not just one fundamental mistake but several.
Fair enough. He also disabled run permissions on the script. But my point isn't really about "just comments", it's that good programmers take responsibility for failures that arise from their work. In this case, printing "DO NOT EVER RUN THIS SCRIPT" and exiting without doing anything led to misunderstanding and problems in the hands of a curious and inexperienced successor. Here the author had a choice to make. He could look at how his rather hokey strategy contributed to the failure or he could hype up the stupidity of the other guy.
I don't know who's the bigger idiot the new guy or the author... and when I think about it I think it's the author. I can understand having a script that recreates the tables from scratch, but why include the drop table line?
If I actually had to worry about working with someone like the guy in the article, I'd go further and create my own "shell" that would pretend to run the commands but would otherwise syslog/page me whenever someone actually ran it.