Resolution to 'Mysterious' Bash Script Error
(to skip to the very heart of this post, click here. otherwise humor me and read until you get to it 
)
So I was sitting there working on a CF-based resume builder app when my boss walks in and asks me to take over responsibility for our company's database and then implement a solid backup plan and policies. I'm still new to this job and so haven't been privy to anything database as of yet, but, how hard can it be? I heartily accept (because accepting requests makes the boss happy) and then proceed to track down all the particulars of our database so I can make this all happen.
The skinny is that our current web application is a very large and disorganized hodge podge of PHP files that run against a mySQL database sitting on an over-priced, shared hosting Linux server somewhere. I FTP the PHP files to my pc and dig through them for some clues about our database and find hard-coded (all OVER the place) the server name, username, password, and database name. "Cool", I say to myself, "I can just use the mySQL gui and continue to explore this puppy. Well, apparently direct connectivity to anything but "localhost" was blocked, so I had two choices for access: phpMyAdmin or telnet sessions via puTTY.
phpMyAdmin does have a feature to allow me to create all the scripts needed to recreate all tables and insert their data. But I wanted a "real" backup as well via mysqldump if possible, so decided to use puTTY and see what I could make happen.
Bear in mind that the last time I did any meaningful work from a command line was somewhere in the late 90s, and I consider doing things that way "last resort", cryptic, and way over complicated. (my personal opinion is that individuals who purposefully CHOOSE to do things the harder more cryptic way when a more user friendly approach exists probably do so in order to make themselves feel smarter. Yeah, I could use the old DOS 'debug' command to find my way into an embedded bios in a piece of hardware I have installed and run its processes that way...but when I have a gui available that does the same thing??? c'mon). Okay, so anyway, I'm staring at a lovely black window with a green square cursor, and an hour later I have managed to piece together what I think is a good start to a bash shell script that will do a "check table" on all of my database's tables, run repair on any that report an error, do a mysqldump on my database, and then ftp the resulting file to a remote server. But, I have a problem (one that consumes the next two and a half hours): my script won't run without immediately throwing a very ambiguous and meaningless error.
I add "-x" after the initial "#! bash" statement so I can maybe get more info, but there's none to be had. After many, many iterations of the same line of code (trying to do a mysql "show tables"), I accidentally happened upon a blurb somewhere out in the ether that caused me to consider the character(s) being used as linefeeds in my script file. I ran a quick regex replace, replacing all \r\n with \n, and lo and behold the script worked!
The Moral of the Story: If you HAVE to write shell scripts in a PC environment, make sure you do a regex replace of all \r\n with \n!
Oh, and do I feel smarter for having managed to create a working shell script from within a PC environment? No. I mean, I do feel a sense of accomplishment that I hung on to this bull and rode it until it submitted to me. But more so I rather feel frustrated that I have to jump through so many fiery hoops to accomplish what ought to be mostly straightforward. Why's the world gotta be so complicated? Oh well, that's another rant altogether.
Hope this saves someone else some time!
Doug out.
)So I was sitting there working on a CF-based resume builder app when my boss walks in and asks me to take over responsibility for our company's database and then implement a solid backup plan and policies. I'm still new to this job and so haven't been privy to anything database as of yet, but, how hard can it be? I heartily accept (because accepting requests makes the boss happy) and then proceed to track down all the particulars of our database so I can make this all happen.
The skinny is that our current web application is a very large and disorganized hodge podge of PHP files that run against a mySQL database sitting on an over-priced, shared hosting Linux server somewhere. I FTP the PHP files to my pc and dig through them for some clues about our database and find hard-coded (all OVER the place) the server name, username, password, and database name. "Cool", I say to myself, "I can just use the mySQL gui and continue to explore this puppy. Well, apparently direct connectivity to anything but "localhost" was blocked, so I had two choices for access: phpMyAdmin or telnet sessions via puTTY.
phpMyAdmin does have a feature to allow me to create all the scripts needed to recreate all tables and insert their data. But I wanted a "real" backup as well via mysqldump if possible, so decided to use puTTY and see what I could make happen.
Bear in mind that the last time I did any meaningful work from a command line was somewhere in the late 90s, and I consider doing things that way "last resort", cryptic, and way over complicated. (my personal opinion is that individuals who purposefully CHOOSE to do things the harder more cryptic way when a more user friendly approach exists probably do so in order to make themselves feel smarter. Yeah, I could use the old DOS 'debug' command to find my way into an embedded bios in a piece of hardware I have installed and run its processes that way...but when I have a gui available that does the same thing??? c'mon). Okay, so anyway, I'm staring at a lovely black window with a green square cursor, and an hour later I have managed to piece together what I think is a good start to a bash shell script that will do a "check table" on all of my database's tables, run repair on any that report an error, do a mysqldump on my database, and then ftp the resulting file to a remote server. But, I have a problem (one that consumes the next two and a half hours): my script won't run without immediately throwing a very ambiguous and meaningless error.
I add "-x" after the initial "#! bash" statement so I can maybe get more info, but there's none to be had. After many, many iterations of the same line of code (trying to do a mysql "show tables"), I accidentally happened upon a blurb somewhere out in the ether that caused me to consider the character(s) being used as linefeeds in my script file. I ran a quick regex replace, replacing all \r\n with \n, and lo and behold the script worked!
The Moral of the Story: If you HAVE to write shell scripts in a PC environment, make sure you do a regex replace of all \r\n with \n!
Oh, and do I feel smarter for having managed to create a working shell script from within a PC environment? No. I mean, I do feel a sense of accomplishment that I hung on to this bull and rode it until it submitted to me. But more so I rather feel frustrated that I have to jump through so many fiery hoops to accomplish what ought to be mostly straightforward. Why's the world gotta be so complicated? Oh well, that's another rant altogether.
Hope this saves someone else some time!
Doug out.
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: Resolution to 'Mysterious' Bash Script Error
You saved me sooo much time with a cygwin bash shell script that was appending \r to commands. After reading your post, I copied the script to a unix shell. I could then see the windows ^M at the end of each line (couldn't see or remove them using vi in cygwin). I removed the ^M in vi using ":%s/^v^M//g" and copied the script back to cygwin. It's working right now! Thanks for the post!
Posted by Janet on May 28, 2009 at 11:58 AM
Re: Resolution to 'Mysterious' Bash Script Error
Glad it helped, Janet! Pay it forward... :)
Posted by dougboude on May 28, 2009 at 12:14 PM