Giorgos Keramidas wrote:

On 2007-10-28 12:54, Andrew Lankford <[EMAIL PROTECTED]> wrote:
Thbbt!  I'm reading the catman version of MAKEDEV.  Wish I could
disable  that "feature".  Oh well.  I'll delete it all and rebuild it
again if needed.  Thanks!

Ah, that's it then :)

My usual `installworld' steps include this too:

        # cd /usr/share/man
        # find cat[0-9] \! -type d -exec rm {} +

This takes care of deleting any `stale' preformatted manpages, so the
next time I ask for a manpage, it's going to be reformatted.
Seems to me that there must a logic error in man. Man makes the effort to check to see if the unformatted manpage is newer than the cat-ed manpage, and if it is, it will try to re-create the cat-ed manpage, and will show you an nroff'ed version of the unformatted manpage if it cannot recreate the cat-ed version.

Clearly that's breaking in this scenario, because the mtime of the new unformatted manpage, while presumably newer than that of the old unformatted man page is still older than the mtime of the cat-ed page.

What seems to be missing, is that when the cat-ed manpage is first created, it should have its mtime set to the same as the mtime of the unformatted manpage, not the time at which you happened to read the man page. I don't see any evidence of that is the sources on my system (which is quite old, but it certainly looks like the bug persists).

A bit of stat and utimes jiggery pokery looks like it would solve this problem. An else clause for " else if (rename(temp, cat_file) == -1) {" in /usr/src/gnu/usr.bin/man/man/man.c would look like the place to do that.

(Alternatively, you could view it as a bug of the install/upgrade process, since it could be argued that the mtime of the unformatted manpage should be the time that the manpage was installed. Presumably that isn't happening, else you wouldn't be seeing the cat-ed version).

Of course, with modern systems where nroff-ing a man page takes negligible time and system resources, it could also be argued that cat-ed man pages should be a thing of the past :-)


--Alex

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to