Perl blog post #6

Been trying to get back into the swing of things at work, so I’ve been doing a bit of Perl coding this week, and I decided to write about it.  Check out the other blog if you like such things.

Next week perhaps I’ll get back to this blog.  Or not.

Postprocedural Meanderings

Well, as advertised last week, I had my minor medical procedure on Wednesday (I generally say “surgery,” but, to be pedantic, it was actually a “procedure” because they didn’t cut me open).  I thought for a while I might be feeling up to a normal blog post, but no such luck.  Of course, you are undoubtedly a highly intelligent person who has determined that they should not read this blog (also as advertised), so you probably don’t care.  But, then, you probably aren’t reading this, so who am I talking to anyway?

Quite the dilemma, indeed.  While I ponder it and hope that I can eventually move past my liquid diet enough to stop feeling continuously faint from hunger, you can feel relieved that you don’t have to listen to me babble this week and look forward to next week, when you can ignore me properly.

Perl blog post #5

Another uber-technology post this week, and, since it involved Perl this time, I decided to post it on my Perl blog.  Continuing in the vein of This vs That, it’s Perl vs Shell Scripts.  Hop on over if you’re so inclined.

Next week, I’ll be recovering from some (minor) surgery, so we’ll see if I have enough gumption to post something.  Wish me luck!

Shell Game

[This week I’m essaying a very technical topic.  This is partially because I want to spit out something fast, and I can do technobabble pretty easily.  Plus I’ve always wanted to write this down, because people—other technogeeks, obviously—ask me about this all the time, and it’s difficult to sum up in a quick sound bite.  But, if you’re not a techie (and specifically a *nix techie at that), you may wish to pretend that I scribbled out another “I don’t have time to write a proper post this week” interstitial post.]

Let’s talk for a moment about shells.  Linux shells, I mean, although we’ll speak in broad enough terms that it shouldn’t matter which flavor of Unix you prefer.  If you don’t what a shell is, you may as well find another blog post to read.  If you do, you probably know most of the history I’ll cover below, but it’s a nice refresher anyway.

The original Unix shell was the Bourne shell (sh), by Stephen Bourne, which goes all the way back to 1977.  Like all things Unix, there was nearly instantaneously a competing product: the C shell (csh), released in 1978, by Bill Joy (who also gave us vi).  The C shell has a number of improvements over the Bourne shell, but they’re utterly incompatible: the syntax isn’t remotely the same, in some cases to the point where you suspect Joy just did the opposite of what Bourne had done, out of spite.  Broadly speaking, the shells that followed hewed to one or the other syntax, giving us two “families” of shells, which are mostly compatible among themselves and not at all with each other.

So, next to come along was the Korn shell (ksh), by David Korn, in 1983; then the Tenex C shell (tcsh), by Ken Greer, later that same year; then the “Bourne-again” shell (bash) by Brian Fox, in 1989.  On the one side, we have the Bourne shell family (sh/ksh/bash); on the other side, the C shell family (csh/tcsh).  There are some other options out there, but these are the most popular by far, with the youngest member of each family eclipsing (for the most part) their elders.  And, these days, bash has emerged as the clear winner, and the others are hardly ever seen.

Well, except on my machines.

You see, I have the following philosophy on *nix shells: use tcsh at the command line; program with bash.  These days, at least on the Linux machines that I work on, that means having to install (or request to be installed) tcsh manually.  Many people ask me why I cling to tcsh.  This post will hopefully explain why.

Now, the first thing you must understand is that, when I came along, it wasn’t a choice between tcsh and bash: it was a choice between tcsh and ksh.  I never even saw a machine with bash on it until sometime in the 90’s, and I was well-established in my patterns by then.  So some of the reasons I made my decisions don’t even apply any more: bash has features that ksh lacked, and is just as good as tcsh these days in many areas, such as history.  But there are still enough reasons that do apply that I continue to refuse to switch.  If you think I’m wrong, though, I welcome your comments to show me the error of my ways.  However, realize that, while I always switch my personal account, I never switch the shell for the root account, so it’s not like I never use bash at the command line.

So, why is tcsh better for an interactive shell?  First of all, let’s look at some of those reasons that don’t really apply any more.  I won’t go into too much detail here, since ... well, since they don’t really apply any more.

• Tab completion.  ksh didn’t originally have it at all; the ‘93 ksh added it, and bash can do it pretty much as well as any other shell around.  But tcsh was basically invented for this, and had it first and best for many years.  Completion of history commands, in particular, I have never gotten to work right in either ksh or bash, although both claim to support it.
• History recall.  Now that bash does it too, it’s easy to forget how awesome !! was when only the C shells could do it ...
• Command line editing.  tcsh lets me use vi keys to edit my command line (which drives anyone trying to use my terminals crazy).  I’m pretty sure bash can do this as well; if ksh ever could, I never knew about it.

Now, what about the reasons that do still apply?  (Or, at least, do still apply as far as I know ... no doubt bash might have snuck some of these in when I wasn’t looking.)

• Shell redirection.  If I want to redirect both stderr and stdout of a command in the Bourne shell family, I have to do something like this: command >/dev/null 2>&1.  Ick.  In the C shells, it’s simpler: command >& /dev/null.  The Bourne versions let you redirect the two separately, true, but, in practice, I never want to do that on the command line.  Whereas redirecting both at once is very common.
• “Separate” environments.  This one is more conceptual.  Shells maintain variables, and those variables can either be visible to subshells (and other child processes) or not.  In the Bourne family, you think of them as two different types of variables.  I can set a variable, and it’s local; I then “export” that variable and it becomes global.  In the C shell family, you think of them as two different sets of variables.  If I want a local variable, I use one command (set), and if I want a global variable, I use a whole different command (setenv).  No mixing.  Perhaps it’s just a personal preference, but this really works for me much better.
• Alias arguments.  All shells will let you define aliases.  But, in the C shells, your aliases can have arguments.  So I can define lln as ls -lhtr !* | tail (and I have, as it happens).  In the Bourne shells, the arguments to your alias go at the end of the command line, period, no exceptions.  If you want it otherwise, you have to write a function.  Why do I want to write a function when I have a perfectly good alias?
• Customized prompts.  It’s true, bash has come a long way in this department.  But I still find tcsh easier.  My current prompt is "[${LOCALHOSTNAME}:%.04] ".  To do that in bash, I’d have to fiddle around with $PROMPT_DIRTRIM or somesuch, and I’m still not convinced I could end up with exactly the same thing.

Now, on the flip side, I would never use tcsh for a shell script.  The only scripting I ever do in tcsh is in my .tcshrc, and even that I find almost unbearably painful.  I regularly have to look up the syntax for loops and even if conditionals.  I originally used ksh for all my shell scripts, and I even held on to it long past the point when it was rational to do so: past the point where I was manually downloading pdksh because no one was shipping ksh any more.  I finally made the switch to bash about 10 years ago, and, other than having to change all my prints back to echos, it was fairly painless.

The definitive proscription against using the C shells for scripting is of course Tom Christiansen’s Csh Programming Considered Harmful, but I’ll give you my personal breakdown:

• Shell redirection.  In a shell script, I quite often do want to redirect stdout and stderr separately, and not being able to do so in the C shells is practically a non-starter.
• Unset variables.  In the Bourne shells, an unset variable expands to the empty string, which makes sense.  In the C shells, it expands to ... a syntax error.  You have to use $?VARNAME to see if the variable is set before trying to use it, unless you’re very very sure that it will be.  That’s just annoying.
• Backquotes.  Trying to use backquotes for capturing command output just sucks.  The ksh/bash construct of $(command) is so much better.  Interpolation works, nesting works, it just ... works.
• Basic string manipulation.  In ksh or bash, I can chop off prefixes or suffixes, do global substitutions, put in default values, and all sorts of other stuff.  In tcsh I pretty much have to echo my variables to sed or somesuch.
• Basic arithmetic.  In ksh or bash, it’s $(( $VAR + 6 )).  In tcsh, I’d have to pipe that to bc or something.
• Newlines in strings.  You just can’t in the C shells.
• Getopts.  No such thing in the C shells.
• Trap.  No such thing in the C shells.
• Extended pattern matching.  No such thing in the C shells.
• "$@".  No such thing in the C shells.

I could probably go on.  Or you could just read Tom Christiansen’s essay, linked above.  I don’t agree with everything he says, and some of what he says is nitpicky and doesn’t actually come up that often, but it’s comprehensive, and Tom has experience with “considered harmful” essays.

So hopefully the next time someone asks me why I still use tcsh, after all these years, I’ll pass on a link to this post and that’ll be the end of it.  I don’t mind switching to newer things when it makes sense (I did, eventually, switch from ksh to bash, as I mentioned above), but right now my .tcshrc is nearly 250 lines of painstakingly handcrafted customization over nearly 20 years, and there’s too much effort for not enough gain to try to get used to bash on the command line.  Maybe one day ... but probably not.  Maintaining compatibility with the Bourne syntax inherently creates some difficulties that I simply don’t have any need or desire to overcome.  Perhaps if tcsh ever gets as hard to come by as Betamax machines or PS/2 MCA buses, I’ll reluctantly give it up.  Until then ... why should I?

The Arrival and the Reunion

Yesterday, at 7:38am PST, we celebrated the arrival of Merrick Elizabeth Brunker Burden.  She was born at home, measured 21 inches from tip to tail, and weighed in at 8 pounds, 1 ounce.  Her Apgar scores were 9 at one minute and 10 at two minutes, and she currently has no known health issues.  She was, as is typically the case, the result of 9 months’ hard work on the part of her mother and a few minutes’ investment on the part of her father.

I’ve already discussed where her first name comes from; her second name is her maternal grandmother’s.  The third and fourth names she’s pretty much stuck with on account of her parents.

The aspect of the home birth was one that we considered for a long time.  Our eldest child was born in a hospital, and we witnessed firsthand how little control one has over the birth experience in that situation.  Our middle child was born in a birthing center, and that meant that our eldest was able to be there at the time and witness the miracle of his brother’s birth.  This was very affecting for him, and I personally always thought it brought them closer together.  A birth center was an option this time around as well, but in the end there’s quite a lot to recommend the home birth.  You don’t have to worry about driving anywhere, which often saves you hours waiting around for something to happen, since you usually don’t wait to be sure that labor is progressing well before rushing off to the hospital.  You get to pick your own CDs to play, and your own food and drinks to consume.  You can have who you want there, and you don’t have to worry about strange people whisking your newborn away to stick them with things that you probably wouldn’t agree to if you really knew what they were.  Best of all, when it’s all over, the mom can just crawl right back into her very own bed and roll over with her new baby and get some well deserved sleep.  Ask any mom who’s delivered in a hospital how much rest they got in that crappy hospital bed.

So we decided to take the plunge and do the birth as births were done for hundreds of years before we decided we were too smart and “modern” for all that nonsense.  When the time came, the mother had a midwife, a midwife’s assistant, a doula, and her mother.  And me, I suppose, although at that point there wasn’t a lot left for me to do.  I got accused of “hovering” a lot.  Which I was, I’ll admit.  Hovering around, trying to be useful, mostly.  Or at least to be out of the way of people who actually knew what they were doing.  It was a bit of a balancing act.  I think I did okay.

It was around midnight when the contractions got down to around 5 minutes apart, and anyone can tell you that that’s well before my bedtime.  So I never actually got to sleep; I lay down with the mother while she tried to get some rest for perhaps an hour and a half, and that was pretty much it until a nap later in the afternoon after it was all over.  Our elder son is as much of a night owl as I am, so he hadn’t gone to bed either when things started to get exciting.  For that matter, our younger son hadn’t been asleep that long.  They managed to wake up for the main event, though.  The eldest handled the video duties.  The soon-to-be-middle-child mainly patted his mother’s face and waited to see the new arrival.

When she came, he was excited for a few minutes, then he was ready to wander off and play video games.  We’ll see if this brings him as close to his sister as it did his brother to him.

Regarding fatherhood, Johnny Depp once said:

Having kids was a huge change for me.  Becoming a father.  But I think more than changing, I feel like I’ve been revealed to myself, I kind of found out who I was.  When you meet your child for the first time and you’re looking at this angel, you start realising what an idiot you’ve been for so many years and how much time you’ve wasted.

Looking into the eyes of your child for the first time is indeed a complex emotion; I think it’s difficult to describe, and probably different for everyone.  For me, there’s some of what Johnny Depp talks about.  Less of feeling like an idiot, perhaps, and more that whatever else there’s been just wasn’t that important ... if not completely irrelevant, at least minimized, as if it was a story about other people, one which was very engaging and seemed important at the time, but finally you’ve realized it is, after all, just a story.  But there’s also something else, something like a feeling of rightness, or perhaps purpose achieved.  Like this was the point of the whole ride, and I just hadn’t realized it before.  It is, of course, slightly different for each child, but still: there’s a lot of familiarity as well, a lot of clicking into place, a lot of “oh, yeah ... I was starting to forget, but now it all comes rushing back to me.”

It’s good to have those feelings renewed again.  It’s good to have another round coming up—scary, of course, as I’m getting older all the time and I worry about keeping up—but satisfying.  I’m very lucky to have the family I do, and I know it.  I’m looking forward to getting to know this little girl, and teaching, and learning, and remembering, and sharing.  Feels comfortable.  Feels like coming home.


Today’s post title comes from a song by Dead Can Dance off their album Aion.  It’s a pretty song, but in this case it’s the phrasing of the title that I’m primarily trying to evoke.