Negix

A search for the right command line option, for the right checkmark to set, or generally the right setting to achieve your goal in some software is something we all did before, at varying levels of desperation and frustration.

We read documentation, we google, we ask questions on StackOverflow or StackExchange or OSDev or wherever we think we have the best chances of getting an answer by a competent individual. And if we play it nicely, we do it in this order.

That isn’t the end of the story, though.

Only searching for the right setting for your immediate problem, and plowing on as soon as you’ve found it, is a recipee for long-time failure. Perhaps not of your project, you might even succeed with that, but failure of yourself as a person.

Once you have found the answer, sit back for a moment and take a second look. At the documentation you have just found. At the Google hits your keywords produced. At the community where you asked your question(s). Instead of applying the answer you got and immediately getting back to producing code, you should take the time to really take in the results of your search.

Interrupting your project for half an hour to really read the blog article, the documentation, to really familiarize yourself with a community relevant to your work, to figure out how it ticks and how you can get friendly and helpful answers without alienating people, is an investment, but it is one that will pay off.

My current project is a somewhat huge translation / re-editing work, and finally gave me the excuse to dabble in LaTeX. Over time, I found the documentation, I found the resource, and I found the community, and I have read much more than what I apparently needed to set section titles just so.

In this, I learned many things I could well use a bit later in my project, I learned things I could use in other projects yet to come, and I learned enough about the subject as a whole to make competent recommendations on to-use-or-not-to-use of LaTeX at my day work, which resulted in significant improvements in our software documentation (both for us doing the writing and our customers doing the reading).

Merely looking for the cryptic commands to set my section titles just so would (perhaps) made me succeed in my immediate project, but wouldn’t have taught me to become a halfway-competent LaTeX user.

I think there is a message in there.

I just read some of my own, old posts (to do something while the compiler is churning away in another window).

More precisely, I read the entry “A quick one”, where I was talking about how to use tee and still check for the success of the tee’d command:

someCommand | tee -a logfile.txt
if [ {$PIPESTATUS[0]} != 0 ]; then …

I do hope it is obvious that, in real life, it should read:

someCommand 2>&1 | tee -a logfile.txt

You do want to get the error messages logged to file, too, don’t you?

Only I found some scripts on our servers that log status messages to file allright, but the errors get printed to the console only… which leads to some awkwardness when the customer calls…

“Hey, this script here failed.”

“No Sir, our logfiles show there has been no error.”

D’oh…

I recently received a mail containing some bug reports and patch suggestions by Rink Springer, who is probably the number #1 guy for putting my PDCLib to the test of real-life applications.

One of them had me gawking speechlessly for some time.

Apparently, several GNU software packages check whether <stdio.h> was included by testing for the _STDIO_H preprocessor symbol.

Read that again. They really have the chuzpe to make assumptions about the exact naming of the symbol used as header include guard - instead of, oh, just include it and have the header include guard do its job?

In other words, my PDCLib <stdio.h> isn’t good enough for them because it uses _PDCLIB_STDIO_H instead.

I’m afraid I am not willing to put workarounds for bugs like this into my code. Wontfix, report to upstream…

I shudder in anticipation as Rink told me he has several other “problems” in this department. Gee, not only do I get reports of all the software that he’s got working on top of PDCLib, I also get new input for this blog here.

For those short of attention span:

Know what you are doing, use what is offered to you.

Crontabs are a powerful feature of Unix operating systems. With a simple command and a line of text, you can set up a command to run repeatedly, at very precisely specified intervalls, to do your bidding.

Most people working on a Unix machine know that.

But apparently most people ignore the fact that any output of a cronjob is automatically mailed to the user running the job.

This is most likely due to the job run as some “technical user”, which was not configured to forward its mail to some real person.

This has several consequences:

1) A script run as cronjob should only generate output in case of error (or for some really important statistics). Forwarding all standard output to a logfile is a smart move; better even is having some rollover tool installed and appending the output to a logfile that contains the last X lines of output at all times.

2) Having thousands of logfiles sit around in a technical user’s unchecked mailbox is several flavors of stupid. Make sure that the mail sent out in case of error actually reaches someone. echo yourmail@yourdomain > ~/.forward. It’s not that difficult, is it?

I had thought these two were pretty obvious. After wading through endless lists of unread tech-user mails on half a dozen servers, it seems I am mistaken.

The only thing not making me hang my head in frustration is the morbid humor of finding out that a good percentage of the cronjobs I was looking at ceased working correctly months, even years ago. No-one ever realized. Finding out might make me look good in front of my superiors, but it doesn’t reflect well on my trade in general…