Follow-up Comment #1, bug #65108 (group groff): This would affect the `\O` escape sequence and the `cf`, `fp`, `hpf`, `hpfa`, `mso`, `msoquiet`, `nx`, `open`, `opena`, `psbb`, `so`, `soquiet`, and `trf` requests.
Right now at least some of these use the internal function `get_long_name()`,
which is inappropriately loose--it's made for reading _groff_ identifiers,
which can contain slashes.
A new, more specialized function for reading file name arguments should:
1. Reject leading slashes, either when not in unsafe mode, or altogether;
and
2. Reject an argument with any slashes in it in the case of `fp` at least, to
avoid having to draw mysterious inferences as in the fix for bug #64577.
Decide what to do about spaces and tabs. One can argue about tabs being
reasonable in file names, but spaces are a fact of life.
As it happens, all requests that take _file_ arguments always do so as the
their *last* argument, thus could reuse optional-strippable-leading-quote
syntax. This would be friendly to users, I think. No new rule to remember
for this argument type.
We might have to punt on \O5, and have "pre-html.cpp" reject an input document
that has spaces or tabs in its name. I know I don't want to add much
machinery just to support generalized _file_ arguments in this one
documentedly internal-use-only escape sequence.
It would seem that AT&T _troff_ users (and _groff_ users to date) have been
pretty conservative about the file names they pass to these requests.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65108>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
