bugGNU roff - Bugs: bug #62787, [troff] standard error output...

 
 

bug #62787: [troff] standard error output should be sanitized

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Wed 20 Jul 2022 08:36:00 AM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 26 Sep 2022 05:54:42 PM UTC, comment #4: 

See bug #63074 for a more general discussion.

G. Branden Robinson <gbranden>
Group administrator
Fri 22 Jul 2022 01:24:09 AM UTC, comment #3: 


comment #2:

>   The bug is in man (man-db) not groff!


comment #0:

> "8 bit characters from the '.tm' request are displayed as \[u00XY]"


This statement doesn't involve the man(1) program or man(7) macro package in any way.  You are describing pure troff(1) behavior.

G. Branden Robinson <gbranden>
Group administrator
Wed 20 Jul 2022 11:08:04 PM UTC, comment #2: 

  The bug is in man (man-db) not groff!

Bjarni Ingi Gislason <bjarniig>
Wed 20 Jul 2022 08:36:59 AM UTC, comment #1: 

Adding Bjarni to CC list.

G. Branden Robinson <gbranden>
Group administrator
Wed 20 Jul 2022 08:36:00 AM UTC, original submission:  

Bjarni reported this issue to Debian about 4 years ago.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906091

"8 bit characters from the '.tm' request are displayed as \[u00XY]"

In bug #62726, I proposed a means of dealing with this.

> Having a stronger `troff` request to sanitize any diversion, string, or macro of node data is a feature that I am increasingly coming to think is both feasible and desirable.  Think, instead of "asciify", "utf8ify".  Anything that can be back-converted to ASCII or a UTF-8 sequence (not forgetting that our old friends the hyphen-minus, caret, tilde, etc. are not ASCII unless remapped) is, and everything else is thrown out.


> I relatedly think that arguments to the `tm` family of requests (including `ab`) should be similarly handled.  I think it would be significant effort for little benefit to add general localization support for troff output to the standard error stream.  That is, I don't want troff to have to care whether the environment uses Latin-1 or Latin-9 or Unicode.  So the argument(s) to these requests would be scooped into a temporary anonymous troff string and then "utf8-sanitized" as described above, then re-emitted.   As a first cut I wouldn't even inspect the environment, but just blast out the bytes in UTF-8 and if somebody's terminal encoding ain't that, they get mojibake.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Updated the item)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by gbranden (original reporter)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-21 barx Summary[troff] standard error output hould be sanitized [troff] standard error output should be sanitized
    2022-07-20 gbranden Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code