[bug #64071] [troff] support construction of proper C strings for request arguments destined for the shell or file system

[G. Branden Robinson]

Follow-up Comment #1, bug#64071 (group groff):

I'm thinking the way to do this is:

1.  Add a function much like input.cpp's `encode_char_for_troff_output()` (as
it is named in a pending push), `encode_char_for_system_output()`.

2.  Have this function encode output much as the foregoing does.  The seven
ASCII specials get translated to ASCII.

3.  Translate Unicode escape sequences of the form `\[u00xx]` as C string
literal octal escape sequences.  I'd prefer '\x', but that's allowed to be of
arbitrary length, and without scanning ahead in the input, I expect this to be
hard to handle.  There is also the problem of ambiguity.  Consider
'\xoobar'.

4.  Reject Unicode escape sequences of more than four hex bytes or where
either of the first two hex digits is not zero.  GNU troff does not futz with
the libc locale, and any other approach would require doing so. 


___

Reply to this item at:

  

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

[bug #64071] [troff] support construction of proper C strings for request arguments destined for the shell or file system

[G. Branden Robinson]

Update of bug#64071 (group groff):

 Assigned to:gbranden => None   


___

Reply to this item at:

  

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

[bug #64071] [troff] support construction of proper C strings for request arguments destined for the shell or file system

[G. Branden Robinson]

Update of bug #64071 (project groff):

  Status:   Postponed => None   


___

Reply to this item at:

  

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

[bug #64071] [troff] support construction of proper C strings for request arguments destined for the shell or file system

[G. Branden Robinson]

URL:
  

 Summary: [troff] support construction of proper C strings for
request arguments destined for the shell or file system
   Group: GNU roff
   Submitter: gbranden
   Submitted: Wed 19 Apr 2023 10:01:11 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Feature change
  Status: Postponed
 Privacy: Public
 Assigned to: gbranden
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 19 Apr 2023 10:01:11 PM UTC By: G. Branden Robinson 
Background, discussing only arguments to the `sy` request.

https://lists.gnu.org/archive/html/groff/2023-04/msg00190.html

I think this will also apply to `pi` and `pso`.

At the same time, we might want to see what our story is with respect to
opening file names with spaces or backslashes in them.  That would affect the
`\O` escape sequence and the `cf`, `fp`, `hpf`, `hpfa`, `lf` (?), `mso`,
`msoquiet`, `nx`, `open`, `opena`,  `psbb`, `so`, `soquiet`, and `trf`
requests.

I expect this will break AT troff compatibility.  But maybe not in a way
that any AT troff user would notice, since if the behavior of DWB 3.3 troff
is any indication, you simply had no way to express C escape sequences that
are valid in string literals via troff requests.







___

Reply to this item at:

  

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