"Surprise, surprise, surprise!"

http://www.house.gov/house/floor/thisweek.htm

(Update—the link above is static, so the content regularly changes. I just checked, and they have already modified the page to obscure the fact that they were not in session monday. Yesterday, it specifically stated that no session was scheduled for Monday, January 8th. Now it simply skips listing monday. Here’s a still image of the current page, since by next week it’ll be completely gone: http://klaatu.anastrophe.com/housesched.jpg )

The pledge that congress would  meet with that ever-so tough ‘five days a week’ schedule, broken after the first week! Reports are that the day was scheduled off due to some college football game that’s of great interest to the members of congress—ah yes, there it is, the Florida Gators vs the Ohio State Buckeyes, played this evening.

Gosh, it sure would be handy if we all could just schedule the day off whenever there’s an "important" event due to take place. I think I’ll officially schedule tomorrow off for myself so that I can pick some daisies.

Politicians. Ya gotta love ‘em. Or do you?

Confession time. I have a nasty habit. It’s filthy, it’s hard to control, I’m guilty of indulging it at just about any time, and I’m really, really, trying to get this monkey off my back.

It’s called "lazy caps".

I’ve been doing it for years. It started innocently enough as merely a bit of rebelling against The Man. I mean, what’s the point? The word "Point" and the word "point" mean exactly the same thing. There’s no difference whatsoever. So if the meaning never changes, why do I have to capitalize point just because it’s the first word of a sentence? Only Fools need Rules, preach it!

The problem is…well, the problem is it makes one look poorly educated and…lazy. Thus, ‘lazy caps’.

Admittedly, I am indeed lazy. No question about it. But I always excused it as being a pragmatic response to expediency. That extra throw of the little finger just to capitalize a letter—it’s wasted effort dang it! And I’m a busy, busy guy! I can’t be troubled with these little nuisances. I have information to share, time is of the essence!

Yeah, right.

Why an entire post about it? To alert my faithful readership that you may note that almost every post here has been – or will be – updated to correct as much of the lazy caps as I can find. So as you’re eagerly absorbed in merriment reading through my vast archives, don’t be alarmed that I’ve gamed the posts to add savory bits for your further titillation. No sir. I’m merely correcting ‘i’ to ‘I’ a few hundred thousand times.

Nearly a decade ago, I came up with a couple of ideas that wound up staying with me all this time. I still use them to this day.

• NOT_IN_SERVICE

Nothing but a directory. That’s it. But it brings a bit of order to the harried sysadmin’s life. Need to muck about with /etc/vfstab, one of those files where the slightest little typo can give you quite a blast of the cold sweats?

cd /etc
mkdir NOT_IN_SERVICE
cp vfstab NOT_IN_SERVICE

Now, that doesn’t seem like brain surgery. And certainly it’s not. But it makes a place where you can keep ‘coordinated’ backups of important files before you muck with them, or move kruft from things you don’t need/use into a place for safekeeping, So they won’t clutter the work environment.  By putting it in all-caps, it provides a bit of a clue to someone coming along behind you—say, if you’re hit by a bus—as to where things might be. At minimum, it’ll tweak their curiousity. It’s a little thing, but I’ve found it very, very handy. There’s NOT_IN_SERVICE directories scattered hither and yon on my servers.

And the other idea?

• /usr/local/admin/bin

Much like any other admin, I find myself writing many, many, little scripts. It’s part of life, shuffling and manipulating data. And /usr/local/admin/bin is where I keep that ‘toolbag’. It keeps the stuff I’ve written separate from the main tree of applications, so they’re all in one place, easy to refer to, particularly when I forget what I named one of them! Obviously, it’s another path to add to your PATH env, but that’s nothing. Late at night, when I just know I wrote a script that does X, Y, and M, but can’t for the life of me remember what I called it—just cd in there, and I know I’ll  spot it in a jiffy. Good luck searching through 300+ commands in /usr/local/bin at 3am.

I’ve seen a number of stories regarding standard Unix commands get promoted to the front page of digg.com. It’s a peculiar phenomenon, at least to me. Most of the articles have been pretty much straightforward explanations of how to use these commands in completely "normal" ways, rather than in novel or innovative ways. I’ve been using Unix since 1986, and have worked as a systems administrator since 1994—perhaps I’m jaded. The popularity of linux has vastly increased the audience for Unix over the years, and that means there’s a LOT of inexperienced people out there who use a Unix-like OS, but have little experience with what was formerly the bailiwick of experts.

That introduction tendered, I’d like to share a mildly novel use of grep that I’ve employed for years. I make no claims to it being truly innovative. However, it is an approach I don’t often see used, and a casual understanding of it should show that it has broader application.

So, on with it!

grep is a standard unix command. It’s included with virtually every flavor of Unix and Unix-like OSes. There are variants of course—GNU grep has considerably more functionality than the default grep that one would find in Solaris a decade ago, for example. This example depends upon the GNU version of grep.

One task a systems administrator performs regularly is checking his systems for ‘unusual’ processes that might suggest something is running on the system that shouldn’t be. Whether it’s an unexpected instance of ‘w’ being run, or ‘rlogin’, or some such—it’s handy to be able to see those oddball apps with as few distractions as possible.

If I run ps -ecf on my Solaris server, I’ll get a listing of every process running at that moment (I prefer the POSIXly functioning ps to the BSDish invocation, which might typically be ps -aux). The problem is, there’s a hundred or so applications listed/running that I know should be running, so I don’t care terribly much about them. I’m interested in those few commands scattered in the output that should not be running.

Culling those unwanted entries from the list is "easily enough" done by just piping the output through several grep -v invocations, for example,  

ps -ecf | grep -v httpd | grep -v imapd

and so on. The problem of course is that you want to cull dozens—maybe a hundred—listed applications, and that can make for an awfully ungainly pipeline!

There’s an easy option to grep though that simplifies the matter considerable—the -f option. -f tells grep to get its arguments from a file, rather than on the command line. In the file, you list—one entry per line—all the apps that you don’t want listed. So, for example, you create a file called curiouspat (or any name to your liking of course), and in it, you list

httpd
imapd
tcsh
mysqld

and so on. You then invoke your pipeline like this:

ps -ecf | grep -v -f curiouspat

and now you’ll get the same output as a long pipeline would produce. The nice side-benefit is that it’s repeatable—you don’t have to keep typing out some ungainly pipeline for all those commands you don’t want to see—and you don’t have to remember them either.

To simplify things further, you can dump the above line into an executable file ( I call mine, naturally enough, "curious") so it’s even easier to run any time. Obviously, your pattern file will likely be quite long—but that’s what makes using a pattern file so much easier than manually pipelining multiple grep -v’s together.

So that’s my tip. Not groundbreaking. Not crazy-innovative. But it’s a handy method  to keep in your toolbag.