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.
I hope that one day, this wisdom will mean something to me.
I keep various project checkouts under a development subdirectory. So I can just do
svn up devel/*
and all of the projects managed with svn get updated. It will automatically skip over the ones that use cvs (or anything else that’s not svn).@Dougal:
That’s a great tip. Too bad I hadn’t realized that prior to the thousands of times I’ve typed those `svn up…` commands.
*sigh*