WARNING: GEEKY CONTENT AHEAD
If you have no desire to read about login shells, Linux, source code management or other similarly geeky content, you’d best be skipping this one. -ed.
Have you ever allowed a nuisance to go on for literally years simply because you couldn’t be bothered to do enough research to effectively nip it in the bud? I personally had two such nuisances (of a particularly geeky variety) come crashing down this past week.
BASHing My Head In
I, like many UNIX users that spend a good deal of time in a command line environment, prefer to customize my environment so that I can save myself keystrokes, work and headaches. Through judicious use of environment variables, aliases and custom shell prompts, I have made it easy for me to be able to determine where in a filesystem I am at a glance, run commands from any number of frequently-accessed binary directories, ssh to my various and sundry boxes, etc. I have done this on every UNIX box that I have spent any considerable amount of time on since at least my early days in college and, as I am a dyed-in-the-wool BASH user, I have always stored my preferences in a file called .bashrc that sits in the root of my home directory. While at Lehigh, having a .bashrc was sufficient to automatically customize my environment every time I logged in. However, ever since joining my current firm, I have been unable to get any of the UNIX boxes at work to recognize my configuration file automatically. Instead, I have had to type bash each time I logged in in order to obtain the customizations.
Two days ago, I had a brainstorm – I realized that some users were known to squirrel their preferences away in a file called .bash_profile and, in a fit of pique, I symbollically-linked my .bashrc to ~/.bash_profile, then logged in to a random UNIX box. Lo and behold, I was immediately presented with my fully-customized shell. I was at once elated and furious – I have, over the past six years or so, typed “bash” countless times, meaning that I could have saved myself and my fingers 4 x countless keystrokes, wear and tear and keyboard mileage. Grrrr.
Subversive Behavior
I update all of the installations of WordPress that I maintain via Subversion and have largely automated the process via a shell script, although I have left a few of them out of the script so that I can update them more and/or less frequently as situations require. In both real-time and in my scripts, I traverse into the base directory of each blog and run a Subversion update; in other words, `cd [blog directory];svn up`. I was goofing around a couple of days ago and decided to actually pass the directory as an argument to the Subversion update, so I ran a test `svn update [blog directory]` from the base of my Dreamhost home directory. Et voila!, it worked like a charm. To date I have thus effectively wasted thousands of both keystrokes and CPU cycles traversing my directory tree instead of simply running a single command.
I share these insights in the hopes that they will save someone, somewhere some measure of blood, sweat, tears, effort and tedious manpage reading.
First off, the development version of WP has been “rebranded” from 1.6 to 2.0 and