[bug #65108] [troff] support construction of general file name request arguments

[G. Branden Robinson]

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