Follow-up Comment #15, bug #65108 (group groff): [comment #14 comment #14:] > So, ideally, we want GNU _troff_ requests to be able to refer > unambiguously to either one.
Yes. And even _more_ ideally, groff would look at its environment and make an
educated guess of how to encode any non-ASCII characters it needs to pass to
fopen().
There are plenty of ways this can go awry, of course: the user's environment
was not necessarily the environment in which the requested file was created,
for instance. But it would be nice if, more often than not, this Just Worked
without the user having to think about encodings and conversions.
> This, I'll quibble with.
I have no quibble with your quibble, but if it changes anything about the
groff file-access situation, I can't identify what.
> * \000 itself won't work as "desired". But this is not a
> practical problem, as 50+ years of Unix and C have led no one
> to expect that they can infix nulls in any file name anywhere.
>
> * The matter of other C0 controls (so, \001 to \037) is a vexing
> one. I would strongly prefer to stay out of the morass altogether.
That's a reasonable restriction. I'd guess the mitigating factor of the first
point also largely applies to the second. The Venn diagram of people putting
C0 characters into filenames and people attempting to write system exploits is
probably a single circle.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65108>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
