Follow-up Comment #3, bug #68497 (group groff):

At 2026-07-04T02:49:27-0400, garavel wrote:
> Follow-up Comment #2, bug #68497 (group groff):
>
> Thanks for the quick reply!
>
> I did not try to compile groff myself on OpenIndiana. I used the groff
> installed by the package manager. "which groff" answers /bin/groff.

Ahhh.

> If you wanr to reproduce the problem on your side; the easiest way
> would be to install OpenIndiana in a VM, which is quite easy. The
> graphical interface of the OS is the same as Linux Debian with Gnome 2.
> Instructions are given here:
> https://docs.openindiana.org/handbook/getting-started/#virtual-machines

Okay, I'll consider that.  But I might not need to--see below.  Even the
easy way is slightly more friction than I'm used to.  :)

> I run the commands:
>
> $ groff -mdoc
> $ groff -ms
> $ groff -me
> $ groff
> $ gtroff -R
>
> followed by Control-D. No output is emitted.

Excellent.  That's all what I would expect, and good news.

> The command:
>
> $ groff -mm
>
> displays the following message:
>
> gtroff:/usr/share/lib/tmac/mmt:2760: error: ignoring invalid numeric
> expression containing an escaped '}'
> gtroff:/usr/share/lib/tmac/mmt:2760: error: ignoring invalid numeric
> expression containing an escaped '}'

Aha!  Whoever built groff for OpenIndiana built it with "compatibility
wrappers".


$ ./configure --help | sed -n '/wrappers/,/man-os/p'
  --with-compatibility-wrappers={check|manual|no|yes}
                          choose whether and how groff compatibility wrappers
                          for vendor-provided non-GNU macro packages are
                          installed. 'check' searches for such packages, and
                          behaves as if 'yes' or 'no' were given, accordingly.
                          'yes' generates compatibility wrappers for the
                          vendor-provided packages to allow their use with
                          groff and related tools. The compatibility wrappers
                          are installed using the vendor-provided names, while
                          their groff implementations are installed with a 'g'
                          prefix. Use of the latter thus requires options of
                          the form '-mg<package>' (example: -mgan). 'no'
                          installs only the groff implementations. 'manual'
                          generates compatibility wrappers for the
                          vendor-provided packages as '<macro>-os'. Use of the
                          latter thus requires options of the form
                          '-m<macro>-os' option (example: -man-os).


groff does not ship a file named "mmt"; when you run "groff
-mm", groff is attempting to interpret _Solaris_'s mm macro package.

That's valuable information.  I suspect "groff -man" reads the
old-school Solaris "man" package sources as well.

And that, it would seem, has employed syntax in a way that I didn't
anticipate when refactoring delimiter handling for groff 1.24.0, even
though I tried to be careful and wrote a large test script.

https://savannah.gnu.org/bugs/index.php?67842
https://savannah.gnu.org/bugs/index.php?67744
https://savannah.gnu.org/bugs/index.php?67408
https://savannah.gnu.org/bugs/index.php?66686
https://savannah.gnu.org/bugs/index.php?63142

https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/tests/check-delimiter-validity.sh?h=1.24.1

> The command:
>
> $ groff -mom
>
> outputs PostScript contents ending with %%EOF.

That's also as expected...and reminds me that I wanted to file a
wishlist bug against mom(7) asking that it not generate a document
preamble until it's seen some input.

> I also tried
>
> $ gtroff -man
>
> which failes with the assertion violation already reported.

Right.  I'll bet I can isolate this bug without a virtual machine.  All
I need is to give GNU troff on my GNU/Linux box Solaris's "man" macro
file as input.  Testing that hypothesis should provide valuable
information.

If I've reasoned correctly about how groff is built on OpenIndiana, then


groff -mgan


...should load groff's man(7) macro package, which _should_ render any
OpenIndiana man page satisfactorily--albeit not necessarily without
emitting warnings.  GNU troff is a linter, and other troffs are not.

Please file another ticket if you find groff man(7)'s rendering of
OpenIndiana man pages to be unsatisfactory.

If you're curious, "groff -mge" and "groff -mgs" should load groff's own
versions of the me(7) and ms(7) macro packages.  If you deal with ms(7)
documents, you might be interested to see the PDF support features
arriving in groff ms(7) in groff 1.25, which I expect to release this
month.

Regards,
Branden



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68497>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to