Hi Morten, At 2026-08-07T12:36:54+0200, Morten Bo Johansen wrote: > This surely is no big deal, but something which on occasion could > present a a user with a wily problem as it just did with me.
Background/documentation: https://www.gnu.org/software/groff/manual/groff.html.node/Macro-Directories.html > Currently, groff prefixes its search path for tmac files with the > user's home directory which means that any tmac files you might have > lying around in your home directory will be used by groff before any > other tmac files, such as the ones from the groff installation itself. Right. > Your home directory is no natural location for tmac files, I hear you > say, but I don't think that I'm the only one who has a bad habit of > not keeping my home directory tidy - it has a tendency to get > cluttered with a lot of different files over time. In my case, an > "s.tmac" file, that once upon a time I had done something with, was > hiding in there and it caused some rendering problems of *.ms files > which I falsely attributed to the groff installed version as I didn't > even suspect that groff would look in my home directory before > anything else. And as you know, one must have at least an inkling of > what a problem might be before being induced to search in > documentation. I agree with you that this is a hazard, especially for the sort of user who experiments frequently. > But these were some specifics to explain how a problem might arise. On > a more principal level, I find it an oddity at best that groff > _prefixes_ its tmac search path with the user's home directory This part, I think I understand. Generally in Unix, search paths are organized in an order that approximates a progression from more recent or more specialized to less. Thus, a common idiom is the following. PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin Historical aside: An early convention for "/usr"[1] was a big disk with lots of stuff that one didn't need in single-user mode. The Unix kernel crashed frequently back in PDP-11 days, and fixing a file system was a slow--and in very early days, manual--process. These days, the purpose of plain "/bin" is largely superseded by an "initrd": an "initial RAM disk" that despite its name is (often) read-only storage despite being kept in volatile RAM--and, typically, discarded entirely with its storage reclaimed late in system boot as a consequence of, on Linux, the pivot_root(2) system call. > therefore I hereby suggest it either be removed - or if being kept in > the search path, then be moved to the end of it. I suggest an alternative pair of choices. 1. Remove $HOME from the default macro search path. 2. Support XDG based directory names for GROFF_TMAC_PATH and GROFF_FONT_PATH instead. https://specifications.freedesktop.org/basedir/latest/ > So, you're hereby invited to raise your thumbs or slam my suggestion > down the gutter. ;) Your proposal has provoked the same sort of response that mine often do. That may be a good sign! Regards, Branden [1] I don't have citations for this, but I think the _first_ application of /usr might have actually been for users' home directories: what we now call "/home". But, as more and more stuff piled into the root file system, "/usr" got reconceived--from "user" to "Unix System Resources"--a backronym. At least that's the quasi-legend as I understand it. I reckon the TUHS list is a good place to test my claims.
signature.asc
Description: PGP signature
