[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

[G. Branden Robinson]

Update of bug #61423 (project groff):

             Assigned to:                    None => gbranden               
                 Summary: allow paths in "name" directive of font description
file, restoring historical groff behavior => [libgroff] allow paths in "name"
directive of font description file, restoring historical groff behavior

    _______________________________________________________

Follow-up Comment #1:


[comment #0 original submission:]
> My system has a /usr/share/groff/site-font/devps with a hodgepodge of font
description files collected over the years through means I don't always
remember.  Most of these files contain a simple "name" directive that merely
repeats the filename.
> 
> A few files contain a full pathname in this field.  These files have worked
fine for the past couple of groff releases, all the way up through
1.23.0.rc1.
> 
> A recent change -- I'm gonna go out on a limb and accuse September's commit
c0d1bb28 <http://git.savannah.gnu.org/cgit/groff.git/commit/?id=c0d1bb28>,
though I've not done before/after testing to confirm this -- now prevents
these files from loading, troff giving up with the error "font description
file name 'JR' does not match 'name' argument '/full/path/to/JR'".
> 
> (In my case, the /full/path/to/JR as specified in the font description file
did not match the actual full path of its final resting place; apparently I
used some tool to generate the file in a working directory, and this tool
encoded the full path of its working directory onto this line.  But even when
I updated the path to match the file's current location, it still failed with
the same error.)
> 
> The current Texinfo document says this directive contains "the name of the
font," which does suggest that /a/list/of/directories before it might be
unexpected.  However, that did work historically.
> 
> Editing the font description file to contain what troff wants here is fairly
simple.  However, is there any benefit to the user of now disallowing a full
path in this field that was previously allowed?
> 
> If so, that's fine, and this change request can be happily closed as "Wont
Fix".  But if not, it might be better to not gratuitously break font
description files that have historically worked.

Hi Dave,

I think you're probably right.  I did not test this scenario.  It is not one I
intended to regress.  I wished only to validate the "basename" of the file
name, and did not consider the possibility of a `file` directive followed by
something with directory components in it.

This does raise the question of Windows file names, where the directory
separator is `\` instead of `/`.  Dealing with this is probably a bit harder
than just calling `strrchr()` on `p` (the directive's argument) and starting
the `strcmp()` from the location it returns, because `\` is an escape
character in C literals.

On the other hand, I don't know what {to, I can} expect from an underlying
Windows C library.  The Windows ecosystem seems to be fragmenting and
resorting to virtualization or WSL, and the last time (or two) I asked for
porting help from Windows users, even just to test a build, I heard nothing
back.  With a sufficiently faithful POSIX layer, Windows doesn't need
different file name handling at all.  And I don't know what the state of play
is.  Apparently Windows 7 was the last version to support Interix, which is
now dead.

I reckon I can fix this problem for POSIX-like systems only and see, at some
point in the future, if someone builds for some Windows-based environment and
complains of it.  Maybe then I can get them to test a fix.  I certainly don't
want to blindly call into the labyrinthine port (rewrite?) of TeX's kpathsea
library we have that deals with these issues.  It's very hard to understand
and no one seems to want to touch it.  (The last time Ingo saw it, he wrote a
lengthy critique.)

As tempting as it would be to say that this is why we don't validate the value
of the `name` directive in the first place, I don't believe that's true.  It
was simply _never_ implemented, going all the way back to 1991.  The `if
(strcmp(p, "name") == 0))` test was followed by a pair of empty braces.  And
in 1991 a port of groff to MS operating systems may well have been regarded as
unthinkable: not only was the 8.3 file name convention the only one available
on the platform back then, but I can't imagine that the C++ compiler situation
was a happy one.  (Back then, the way forward was going to be OS/2, anyway.)

I'll have a look.

    _______________________________________________________

Reply to this item at:

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

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