Don't Abuse the Cat!

I'm a UNIX geek. The first UNIX-based system I interacted with was in 1989 in the second half of my freshman year at Penn State. I've had them as hobby systems for pretty much the entire time since college. I've also worked with them, in a professional capacity since the mid-90s. So, I've got a bit of experience with using them.

With that much time using UNIX systems, I've developed some habits and something bordering on beliefs about how to use them. When people do things that violate those habits or "beliefs", it kinda hits a nerve. One of the biggest (irrational) annoyances is when people fire up two commands to accomplish what could be done with one. The biggest annoyance in this family of annoyances is piping the output of cat to another program that can read the file directly. The most common of these seems to be the infamous `cat ${file} | grep ${PATTERN}`. The one that probably annoys me the most, however, is `cat ${file} | more`.

Whut. The. Fuck. Seriously? Did you just type that? Worse: did I actually see you write in an operations guide to use that as a standard procedure? FUUUUUUUUUUUUUUUUUUUUUUUCK

Seriously: I die a bit, inside, every time I witness someone write/say "cat file | grep TERM" (or similar). There's been more than a few SA's (team members, customers, etc.) that have heard me bellow, "don't abuse the cat!"

Annoying Defaults

I've said it many times before and I'm sure I'll say it many times in the future: every operating system sucks. If you haven't found what it is that makes your particular-favorite suck, you haven't been using it long enough, hard enough or both (either that, or you're just deluding yourself).

One of my co-workers is a Windows geek (well, it's what he's most comfortable using, any way). He likes to make cracks about Linux as though it will insult me, somehow. I'm not sure why he thinks this will work. I mean, it's not like I wrote Linux, so, I don't have any personal stake in it. But, whatever. Hell, I'll be the person at the head of the line to recite my own list of grievances about it. I'd be the first person at the head of the line bitching about pretty much any piece of technology I've used more than casually.

At any rate: Linux...

There are quite a number of things that I hate about Linux. In fact, when the previously-mentioned co-worker said to me, "Linux sucks," I agreed. I did, however, also say, "but it still sucks less than Windows."

One of the things I have always hated about Linux is its default shell. AT&T-derived UNIX operating systems use the old, bog-standard Bourne shell (/bin/sh) as their default shell. The BSDs brought us the C-Shell (/bin/csh) as the default shell (though, some derivatives later shifted to the TENEX C-Shell - /bin/tcsh). IBM and SGI decided that their OSes, being more up to date derivatives of the AT&T UNIX should have a more modern default shell. Both chose to have Korn Shell (/bin/ksh) as their default login shell.

I used to work for SGI. I've done a lot of work on IBM UNIX systems (AIX). So, I got used to having KSH as my default login shell. I also do a lot of scripting. KSH supports standard Bourne shell syntax but adds a number of useful extensions - in particular, I like the internal function construct. So, at this point in my UNIX-using career, I prefer KSH to all other shells.

Linux, unfortunately, being a "UNIX work-alike", has a different default shell than all other UNIX(y) operating systems. All of the previously-mentioned shells used to not be fully "in the public domain". So, when they needed an interactive shell, the Linux-coders came up with the Bourne Again Shell (or 'BASH'). It's kind of a hodgepodge of all of the shells that had existed when BASH was first created. It offers a lot of featuer-commonality with the other shells, plus some of its own tricks. Unfortunately, as with any "be all" solution, it's a giant ball of compromise rather than being particularly optimized.

Any way, none of that is exactly germane. The particular beef I have with Linux is the use of color in many applications and tools outputs. Where I particularly see it is in the output of the directory listing command, `ls`. In most of the Linux distributions I've used, the default login preferences specification turns on the use of color in the out put of `ls`. The output is what I refer to as "angry fruit salad." It's lots of garish shades of yellow, red, green and blue. It's rather hard to read.

Angry Fruit Salad

If I have rights to disable it, I immediately change the login profile to get rid of it. Unfortunately, it's usually the case that I don't have the rights to permanently disable it. So, the best I can do is, immediately upon login, is do `unalias ls`.

But... I shouldn't have to! Criminy: whose brilliant idea was it to make the BASH default alias for `ls`  display in color???

I hate "fixing" something when I can neither fully explain why it was broken nor why the "fix" works.

On my technical blog, I recently went through how I worked around what seemed to be brokenness in Linux's routing. I'd done a fair amount of digging around to try to solve my problem. I even asked questions on some forum sites (to no avail). Eventually, with enough persistence, I cobbled together a solution.

Unfortunately, that wasn't quite enough for me. I mean, I had an observed behavior I was trying to surmount, but, hadn't had the tools to really tear it apart. So, I was treating symptoms rather than finding a cure. I hate that approach to problem solving.

So, today, since I had some time, I broke down and tried to see what was really going on under the covers. I wanted to sort out the root-cause of the symptoms I'd addressed. So, I downloaded tcpdump and tried to watch my packet flows both with and without the "fix" in place.

Even with what should be the right analysis tools in place to see the problem, it wasn't any more enlightening. The error I expected to see wasn't there. Worse, there wasn't really any alternate error in its place. Fucking. Maddening.

I still have the urge to track it down further (yeah, OCD!), even though I know that it's mostly wasted effort. I mean, the issue I ran into shouldn't happen in production situations, and, even if it did, I've documented the "fix" for it. I just don't like not knowing why it was broken or why my "fix" works.

Gah... I'd be ill-suited for work in medicine or other theoretical scientific endeavors.

Need Better Outlets

Posting to Linuxquestions.Org seems like a waste of time if you have other than "home user" level questions. I mean, it's awesome that so many people find it to be a useful site, and, they do have an "enterprise" section. It just seems like there's not a lot in the way of good, in-depth/technical resources out there for people who really want to use Linux. Oh well. I'll keep posting there, even though I never get answers (unless you count the "your question has no replies after 'X' days" emails).

No KSH Love

I've been using UNIX operating systems (and workalikes) for a long time, now. The first UNIX system I touched was in 1989. As a longtime user of UNIX, I've developed some deeply set habits and preferences.

One such preference is my choice login-shell. I am a Korn Shell (KSH) user. Unfortunately, it's not super well-supported under Linux. It's made available more as a concession to dinosaurs, such as myself, than as a real "we think this is a good shell" type of effort. While each of the other myriad shells in Linux seem to come with a default shell initialization script in /etc/skel, KSH is given no such file.

All I can guess is that the distribution/package maintainers figure, "if this person's using KSH, they have enough clue to know how to put together a proper shell init file - no sense bothering to provide one." Worse, so few of today's UNIX "administrators" seem to get that there's shells other than BASH, that they don't bother to alter the contents of /etc/skel (or, if they do, they only do it for BASH and maybe CSH). Then again, there's a reason I put quotation marks around "administrators".

Shortcuts

At the end of the day it's easier to write patch for /etc/init.d/winbind than to debug requisite SELinux policies.