groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] pdfroff 1.22 calls groff 1.19 -help


From: Steffen Nurpmeso
Subject: Re: [Groff] pdfroff 1.22 calls groff 1.19 -help
Date: Fri, 29 Jan 2016 13:22:10 +0100
User-agent: s-nail v14.8.6-160-gb8bd20a

Anton Shterenlikht <address@hidden> wrote:
 |This is on FreeBSD 10.2-RELEASE-p9,
 |with base OS groff, /usr/bin/groff at 1.19.2,
 |and groff-1.22.2_3 istalled via packages
 |under /usr/local/bin.
 |
 |When I try to run pdfroff 1.22, it pulls
 |groff 1.19:
 |
 |$ /usr/local/bin/pdfroff --version
 |GNU pdfroff (groff) version 1.22.2

This script will prefer environment variables GROFF_BIN_DIR then
GROFF_BIN_PATH (why is all that, btw.?  pffffh!) falling back to
PATH as a last option only.  So doing

  $ ( GROFF_BIN_PATH=/usr/local/bin/; $GROFF_BIN_PATH/pdfroff )

should do it, no?  Not seldom the quality of packages is really,
really regrettable.  But it seems to me here some configure /
compile time setting is truly missing.  (For the future S-roff
i would really like to see that we have outsourced shell (and
perl++) "libraries" which get sourced in by such scripts, and can
be sourced in by possible user scripts.  Just like, e.g., git does
it.  In there variables like $INSTALL_BIN -- or whatever! -- can
easily be distributed to any user.)  On the other hand it seems to
be common sense that users are responsible for their $PATH, so if
you use the package system which adds in /usr/local then you
possibly should place /usr/local before /usr in $PATH, since
otherwise anything in base will be used in preference.  Right. :)

 |However, 1.19, the base OS version is drastically
 |cut down to the bare necessities of building FreeBSD
 |man pages only, so it does not have spdf or pdfmark
 |macros, hence the error:
 |
 |$ /usr/local/bin/groff -Tpdf -mspdf z.1 > z.pdf
 |$ /usr/local/bin/pdfroff -mspdf z.1 > z.pdf
 |troff: fatal error: can't find macro file spdf
 |troff: fatal error: can't find macro file spdf

So this should magically disappear, too, then.  It seems to be common
sense that this error message is even verbose, but some reference
to $GROFF_TMAC_PATH, and/or the complete search-path, would make
sense more easy for users i think.

--steffen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]