#995 man pages broken on Solaris

output: manpages
XSL (1066)

Between 1.73.2 and 1.74.0, the manpages have ceased to work on Solaris or even on a slightly old Linux installation. I'm using Solaris 10 and SuSE ES9 which has groff 1.17.2.

On Solaris, I get only the header and footer lines. Removing the toupper and SH-xref macros basically fixes it but I still get FC and F[] surrounding some items that were marked <literal> or <email> in the Docbook source.

The FC/F[] problem also occurs with the old Linux machine.

On a recent Debian Linux machine (groff 1.18.1), the man page looks fine. No formatting is applied to the <literal> elements and the e-mail address no longer has angle brackets around it as with 1.73.2.


  • Michael(tm) Smith

    • priority: 5 --> 7
    • assigned_to: nobody --> xmldoc
  • Michael(tm) Smith

    Logged In: YES
    Originator: NO

    > Between 1.73.2 and 1.74.0, the manpages have ceased to work on Solaris or
    > even on a slightly old Linux installation. I'm using Solaris 10 and SuSE
    > ES9 which has groff 1.17.2.

    Well, that's not good... I will try to get this fixed as soon as possible. But for now, the workaround is to just use 1.73.2


  • Mauritz Jeanson

    Mauritz Jeanson - 2009-02-06

    My understanding is that "classic" nroff, not groff, is used on Solaris. The following might help in resolving the bug.

    According to Troff User's Manual, troff/nroff macro names may be one or two characters long. groff does not have this restriction. This could explain the trouble with the toupper and SH-xref macros.

    In the define.macros template, SH and SS are redefined using the .de1 request. This request appears to be available in groff only.

    See also this patch:

  • Michael(tm) Smith

    I really do need to get this fixed. I'll try to get the changes made next week, and get them checked in. I think I will need to add a new parameter named "man.custom.macros.enabled" (or something), with it set to True by default. Setting it to False would cause the custom macros to not be included in output, and normal requests/escapes to be used in the output (instead of the custom macros). I would really like to have access to a Solaris machine that I can test on. I think Sourceforge used to provide shell access to a number of different build machines, with a variety of OSes, including a Solaris machine. Not sure if they still do. I'll check.

    Anyway, once I do get this fixed, we'll do a new release, 1.75.0.

  • Michael(tm) Smith

    After looking around a bit, I see that SF not longer provides public shell access to their "compile farm" machines. So I'll try to see if I can find a Solaris machine somewhere else that I can get access to and test on.


  • Oliver Kiddle

    Oliver Kiddle - 2009-02-07

    An alternative to finding a Solaris machine might be to try to Heirloom Documentation Tools on Linux (http://heirloom.sourceforge.net/doctools.html). Otherwise, it isn't too hard to run OpenSolaris in VirtualBox. Unfortunately all the Solaris boxes I use are on a secure LAN so I can't offer you a login. I should warn you that I've got one more manpage bug that'll I'll be reporting on Monday. I would have reported it yesterday but I'm hoping to have a patch done.

  • Michael(tm) Smith

    A fix for this issue has been added to the current codebase.
    Please test the fix with the latest snapshot from:


  • Michael(tm) Smith

    • status: open --> pending-fixed
  • Oliver Kiddle

    Oliver Kiddle - 2009-02-10

    I have tried the snapshot and the man pages do appear to be working again. Thanks.

    Angle brackets where <email> was used are still gone but that's minor.

  • Oliver Kiddle

    Oliver Kiddle - 2009-02-10
    • status: pending-fixed --> open-fixed
  • Michael(tm) Smith

    • status: open-fixed --> pending-fixed
  • Michael(tm) Smith

    I think the "angle brackets where <email> was used are still gone" was an intentional change. I thought I might have added a parameter for re-adding them optionally, but perhaps not.

  • SourceForge Robot

    • status: pending-fixed --> closed-fixed
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks