Follow-up Comment #9, bug #68597 (group groff):
[comment #7 comment #7:]
> You were right. A stray s.tmac had somehow found its way into the root of my
> home dircetory and which I had completely forgotten about, so you may close
> this as invalid. Still, I wonder why groff doesn't always look first in
> ${prefix}//share/groff/current/tmac
It's not straightforward for me to trace the history of this arrangement back
before 2014, when Bertrand ported _groff_'s build system to Automake.
But here's how the macro ("tmac") search path is constructed.
$ nl -ba Makefile.am | sed -n 142,161p
142 # 'tmacdir' says where to install macros.
143 tmacdir=$(datasubdir)/tmac
144
145 # 'systemtmacdir' says where to install platform-dependent macros.
146 systemtmacdir=$(libprogramdir)/site-tmac
147
148 # 'localtmacdir' says where local files will be installed.
149 localtmacdir=$(dataprogramdir)/site-tmac
150
151 # 'appdefdir' says where to install the application defaults file for
152 # gxditview.
153
154 # glilypond_dir
155 # gpinyin_dir
156
157 # 'tmacpath' says where to look for macro files. The current
directory
158 # is prepended at run time in unsafe mode only; the user's home
159 # directory is always added. "troffrc" and "troffrc-end" (and
"eqnrc")
160 # are sought neither in the current nor in the home directory.
161 tmacpath=$(systemtmacdir)$(RT_SEP)$(localtmacdir)$(RT_SEP)$(tmacdir)
Our _troff_(1) man page says a bit more:
GROFF_TMAC_PATH
A list of directories in which to search for macro files.
troff will scan directories given as arguments to any
specified -M options before these, then the current
directory (only if in unsafe mode), the user’s home
directory, a site‐specific directory (/home/branden/
groff-HEAD/share/groff/site-tmac), and a standard location
(/home/branden/groff-HEAD/share/groff/1.25.0/tmac) after
them.
(These exact paths correspond, as you may guess, to my crazily bleeding-edge
working copy. Yours will differ.)
_Why_ is the search path organized the way it is? To be sure, we must ask
former _groff_ maintainers.
But my surmise is for user convenience in overriding or replacing system macro
files, by analogy to the long-standing Unix tradition of organizing the
command search path.
Here's a pattern you'll often see there.
PATH="$HOME"/bin:/usr/local/bin:/usr/bin:/bin
(In days of yore, "/usr" tended to be stored on a large disk drive distinct
from the smaller "boot" disk housing the root partition used to bring up the
system. Among other frustrations, _fsck_(8) took forever in early days--to
say nothing of pre-_fsck_ days when you'd have to use inscrutable
Thompsonesque tools like _dcheck_ and _clri_. System downtime was minimized
for administrators--and sometimes consequently users--by getting the "base"
system up and potentially into a limited multiuser environment ASAP after a
crash. Multiple operators--or the same operator using multiple
terminals--could sign in and then run _fsck_ concurrently by hand on multiple
volumes that needed _fsck_ing.)
On some System V-ish systems, you might have found "/opt/bin" immediately
before or after "/usr/local/bin".
I suspect similar reasoning was applied here. Observe the sequencing:
* `-M` macro directory arguments specified on the command line
* "." (unsafe mode only): whatever's sitting "right here" relative to the
document
* $HOME: user's customized macro package extensions or replacements
* /usr/share/groff/site-tmac: site-local macro package extensions or
replacements
* /usr/share/groff/1.25.0/tmac: stock macro packages as shipped by GNU
One can observe a pattern of the more specific preceding the more general.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68597>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
