This Space for Rent

Annoying Unix featurette of the day

Postoffice comes with a much more complete set of manual pages than most of my other code comes with, and I was fairly pleased that I was actually able to get these pages written (most of them using the same macro set that the Allman sendmail (8.8.5, I think) I used to use used. Why? I hadn't written the manpages for postoffice yet, so the sendmail manpages were still lying around) and they actually more-or-less described the code as written.

So I had a working mail server, working manpages, and everyone was happy, right?

Um, wrong. About the time I was finishing up with the great netbsd/sparc64 portability dance, Pierre-Philipp Braun sent me a note saying, more or less, "if you're going to do feature enhancements, could you modify the manpages so apropos works for them?"

Um, what, you mean it doesn't work now? <clickity clickity> ... Um, no, they don't seem to work on either Mastodon, FreeBSD, or NetBSD. And it appears that they don't work because I used the wrong set of manpage macros.

So...

.SH NAME
.Nm smtpd
.Nd the
.Nm postoffice
SMTP mail server
... does not work, but ...
.SH NAME
.Nm smtpd
.Nd the postoffice SMTP mail server
... does work (on FreeBSD; the horrible script that is left over from the original manpages on Pell simply ignores (or eats) the NAME section.)

It looks like if I want it to work on Pell (and any other version of Linux that continues to use the horrible script that I'm using) I need to redo the manpages in the stupider BIG LETTER MACROS AND NOTHING FANCY LIKE TABLES format that so many other manpages use.

Or I could just drink heavily.

All hardware sucks, all software sucks, and I can't take a hammer to the software.

Comments


I’ve been working some changes into someone else’s php scripts. The server this stuff is hosted on is still running php3 and postgres 7.0.

To work on it, I brought it down to my machine which is running php 4.4 and postgres 8.0.

Mostly it all still runs. Mostly. Several function names have been changed for no useful reason (i.e. pg_numrows is now pg_num_rows). Also, many variables have been collected into a few arrays. As far as I can tell, these changes were all for cosmetic reasons.

It meant several hours of writing ifdef-style statements to run the right version of the script for the right version of the php.

It isn’t the same kind of grand problems I’ve read about in your blog, but it is enough that I can really feel your pain. :)

Lynn Sun Feb 12 13:33:30 2006

PHP is *special* in that way; the people who are, um, ‘designing’ that language are taking all of the already-horrible “let’s redo this feature in a completely incompatable way!” tendency of open-source software and enshrining it as the central concept of their language. So if you think that perl and python don’t mutate fast enough for you, and you think that the completely broken and stupid gcc-isms that make up the C99 “standard” (motto: you cannot escape c++) are a timid example of a bureaucracy in action, PHP is the language for you.

I, fortunately, am not in the PHP ghetto at work, so my interaction with the PHP version of the day is restricted to listening to the developers complain about PHP 5.x.y.z.e.y.1 working completely differently than PHP 5.x.y.z.e.y.2, and in such a way so that system libraries don’t actually install from the distribution CDs. Their wills have been broken to the point where spending a month or two fighting the libraries is just another day’s work.

David Parsons Sun Feb 12 16:35:53 2006

Comments are closed