Ahh, The Incredible Machine. What a great video game. A basketball would roll down the slope, hit a bucket attached to a rope which was networked through a complex system of pulleys, pulling a lever that would turn on a motor, sending a conveyor belt in motion, carrying a baseball into a seesaw connected with string to a gun that shoots a cat in the face.
Shooting a cat in the face, incidentally, is more humane than subjecting an innocent developer to a horrible, Rube-Goldbergian system that our poor friend RJ had to maintain. I'll step aside and allow him to explain.
Now I like Unix as a concept as much as the next techie, but one set of shell scripts left by a predecessor gave me a whole new appreciation for how much work some will do to imagine they are working in the Unix tradition:
I had just taken over as IT Director (read: developer and administrator) of a small web-based company which provided online money transactions (similar to systems developed by another company whose name rhymes with "Hey, pal"). One of the main daily processes was an ACH banking script that had to run once a night to read all pending transactions and actually transfer the "real banking" money behind the online fund activity. I had been asked to update this code for our DBMS migration, and the anxious look on the Operations Manager's face struck a death knell of fear into me. Apparently, this script had taken weeks to produce, and was the most revered "mission critical" piece of the system. I was a little intimidated, what with the serious nature of banking transfer and all that.
After a few questions, I began to piece together how this thing actually worked: once a day the manager (a non-technical employee) would log into the main Linux server *as root*, cd to a directory inside /usr, run a certain shell script, and pipe the output to the Unix 'mail' utility to email it to his own desktop. From there, he would copy the text into Wordpad, make sure all formatting was correct, and then run that classic Windows dial-up console, Hyperterminal. He would dial the bank system, log in, and finally paste the ACH text from Wordpad into Hyperterminal to finalize the transactions.
I was already counting on both hands the number of failure points in this system when I decided to have a look at the shell script. Did I say script? No, it turned out to be a collection of scripts. Now, ACH is a simple fixed-length batchfile structure. You have a header, a group of individual transaction records, and then a footer. A simple matter of querying the database and piecing together the values, right? Nothing could have prepared me for what I saw.
The first script would build an SQL query and then 'cat' that string to a text file. Then it would run a second script which piped *back in* that SQL query from the textfile, running the query in the database, and outputting the query results (in console form with "|" delimiters and all) to another text file. Then that script would run another script to cat the query results to yet another script that ran a series of calls to various Unix text-processing utilities: 'grep' that, 'sed' this, 'awk' the other, creating another SQL script for the individual record subquery, pipe those results to text *also* to be parsed, trimmed, padded, calculated, etc... In the end it created at least 8 different text files in the process, and then *finally* ran a script that combined these text files into the complete ACH batch format. And by the way, there was not a single comment in any of these scripts. I realized I was facing nothing less than a complete rewrite. Then I pondered: hmm... doesn't SQL have text manipulation functions? Doesn't it have LPAD, RPAD, concatenation operators, etc... On thinking it through, this whole thing could be done with a 10 line script running 3 SQL queries. But that wouldn't be very Unix-ish, would it? Did I mention that the person who did this took weeks...?