Follow-up Comment #17, bug #68497 (group groff): At 2026-07-06T05:11:37-0400, garavel wrote: > Follow-up Comment #14, bug #68497 (group groff): > > A side remark: replacing groff -man by groff -mgan raises no exception > on all my man pages, but one, which contains an instruction: > > .if t .so /usr/share/lib/tmac/ms.acc > > which triggers the following error: > > gtroff:<standard input>:5: error: cannot open '/usr/share/lib/tmac/ms.acc ': > No such file or directory > > The point is that there was a trailing space after ms.acc. groff -man > removed it silently, but groff -mgan takes it seriously as part of the > file name. I let you decide who is right.
Well, it was my decision to reform the groff language in this way, so I
may be conflicted out on making that decision.
I advise you to slightly alter that one man page of yours as recommended
in groff 1.24.0's release notes or the corresponding entry in its "NEWS"
file.
VERSION 1.24.0
==============
Noteworthy incompatible changes
-------------------------------
* If your roff(7) documents follow any of the requests `cf`, `hpf`,
`hpfa`, `mso`, `msoquiet`, `nx`, `open`, `opena`, `so`, `soquiet`, or
`trf` with a comment after their file name argument, and did not
place that comment immediately after the file name, you are likely to
get a diagnostic message resembling the following.
warning: cannot open macro file 'e.tmac ': No such file or directory
Or, less likely, the formatter will open the wrong file, one with
spaces at the end of its name. That is because these requests are
now able to process file names containing space characters. (This
change also makes the request syntax consistent with that of `ds`,
`as`, and others.) A quick fix is to place the comment escape
sequence as early as possible. For example, we would change:
.mso e.tmac \" Load Eric Allman's package.
to:
.mso e.tmac\" Load Eric Allman's package.
to tell the formatter to load the "e.tmac" file rather than
"e.tmac ". See the items below for further details.
> Is there a more portable way of importing ms.acc, without having such
> hard-coded absolute pathnames?
I don't know of one that's completely portable. AT&T troff had no
concept of a "tmac search path", and I think this fact was generally
understood to be a limitation, judging by the hacks undertaken by 1980s
projects that sought to be portable to both BSD and System V flavors of
Unix. (BSD was "stuck" on Seventh Edition Unix troff [1979], whereas
System V seems to have used the later DWB 2.0 troff [~1984] or something
close to it. The latter relocated the system's macro packages from
their Seventh Edition location.)
GNU troff _does_ have a tmac search path, supports an environment
variable permitting its configuration, `GROFF_TMAC_PATH`, offers a `-M`
command-line option permitting further configuration of that search
path, and finally its `mso` request traverses that search path.
There's more info about this stuff in the _groff_(1) man page.
https://man7.org/linux/man-pages/man1/groff.1.html
Heirloom Doctools troff claims to support `GROFF_TMAC_PATH` and `mso` in
its "groff compatibility mode". I haven't evaluated it for operation
consistent with GNU troff.
Neatroff appears not to support `mso` at all, but it also has no man(7)
package and I've never heard of anyone using it for man page rendering,
but it _is_ theoretically possible.
_mandoc_(1) refuses to support `mso`, characterizing it as "insecure".
The Plan 9 troffs maintained by the "9front" and "9fans" do not support
`mso`.
That does it for the *roff interpreters I know of that are even
nominally maintained. Heirloom, for example, has seen no commits at all
in almost two years.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68497>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
