bugGNU roff - Bugs: bug #55695, troff outputs garbled file names...

 
 

bug #55695: troff outputs garbled file names on MS Windows

Submitter:  Eli Zaretskii <eliz>
Submitted:  Mon 11 Feb 2019 05:25:48 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Invalid
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 31 Mar 2023 10:48:30 AM UTC, comment #5: 


> Most programs and (internal, static) libraries in group


...in groff...

G. Branden Robinson <gbranden>
Group administrator
Fri 31 Mar 2023 10:47:51 AM UTC, comment #4: 

Thanks to the anonymous clarifier for the the clarification.

Most programs and (internal, static) libraries in group open files via standard C library I/O streams (in other words, with fopen()).

There are a few exceptions I'll survey here.

1. groff's Perl programs use Perl's open(); I don't know what Perl does under the hood.

2. In a few places, the open() system call is employed.  With one exception that I see, this practice corresponds with opening files in "binary mode".  Much of groff's code base is 30+ years old.  Perhaps back then, the letter "b" in fopen()'s mode string was not as portable as one would have hoped (ANSI C being only a few years old at that point).

3. In one place (xtotroff.c), open() is used (followed by fdopen()) to create a destination file corresponding to a command-line operand, to avoid racing with other file system operations (or, rather, to fail if a race occurs).  ISO C11 added the letter "x" as a valid character in fopen()'s mode string to support this usage.  It is possible that this is not yet as portable as we would hope today.  In 2019, Nick Stoughton of the Austin Group (the POSIX standardization committee) raised an issue with WG14 (the ISO C standardization committee) regarding the semantics of fopen(..., "[rw]x").

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2357.htm

I haven't chased down if/how that issue got resolved; it doesn't matter for my purposes because I figure groff code cannot expect reliable semantics from the "x" mode flag on the environments to which we want to be portable for some years yet.

However, I observe that:

A.  We might want to start migrating to fopen(..., "[rw]b") in the cases of item 2 above; and

B.  We already use gnulib.  Maybe gnulib has modules that would help us out here, and we could stop dropping all the way to system calls for opening files entirely.

Either of these would be a good item for a groff contributor to take up.

The bottom line is that file specifications supplied to any groff program in any way (as command line operands or appearing in input streams, for instance as arguments to `so` or `mso` requests) should use forward slashes as the directory separator.

Despite being written in C++, groff largely does not use the standard C++ library, notably including its iostream facility, which was in place before most of the rest of it (including the notorious template library).  I have no ambition to change this.

Resolving as invalid.

Dropping patch annotation from invalid ticket.

Also, as noted in bug #55299, Achim Gratz is maintaining groff for Cygwin now, not Brian Inglis.  Thanks for the correction.

G. Branden Robinson <gbranden>
Group administrator
Fri 31 Mar 2023 04:32:05 AM UTC, comment #3: 

Most Cygwin packages and GNUtilities no longer support native Windows paths,
unless they happen to pass them verbatim down to open,
where the file handler may recognize the format and bypass POSIX to Windows path mapping.
This is used to provide Windows compatibility in some cases
and much of the Unix special file system emulation
e.g. /dev, /mnt, /proc, fifos, ioctls, pipes, sockets, SHM, SysV IPC.
Cygwin now does not differ much from Linux (originally was Solaris):

$ ls -glo /usr/share/man/man1/addr2line.1*
-rw-r--r-- 1 4658 Feb 12 05:38 /usr/share/man/man1/addr2line.1.gz
$ troff -ms \usr\share\man\man1\addr2line.1.gz 2>&1 > /dev/null | cat -A
troff: fatal error: can't open 'usrsharemanman1addr2line.1.gz': No such file or directory$
$ troff -ms '\usr\share\man\man1\addr2line.1.gz' 2>&1 > /dev/null | cat -A
troff: fatal error: can't open '\usr\share\man\man1\addr2line.1.gz': No such file or directory$
$ troff -ms addr2line.1 2>&1 > /dev/null | cat -A
addr2line.1:136: macro error: .TH without .TS H (recovering)$


Anonymous
Thu 30 Mar 2023 11:08:46 PM UTC, comment #2: 

Adding CC of Brian Inglis, who now takes care of groff for Cygwin.

Brian, can you comment on this issue?

G. Branden Robinson <gbranden>
Group administrator
Wed 21 Oct 2020 07:32:28 AM UTC, comment #1: 

Do we have someone with access to a Windows machine to test this on?

Eli filed it almost immediately after the previous release; it'd be nice to do something about it before the next one.

G. Branden Robinson <gbranden>
Group administrator
Mon 11 Feb 2019 05:25:48 PM UTC, original submission:  

A command such as this:

      troff -ms \usr\share\man\man1\addr2line.1

when invoked on MS-Windows, produces the following diagnostics:

  \usr\share\man\man1☺ddr2line.1:136: macro error: .TH without .TS H (recovering)

The funny smiley after "man1" is the glyph produced by emitting a Ctrl-A (ASCII 0x1) code on the Windows console.  The reason for this is that the backslashes in the file name are interpreted.

Is the attached patch a good way to fix this?

Eli Zaretskii <eliz>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46235:  DIFFS_troff_backslashes added by eliz (800B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (new groff maintainer for cygwin)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by eliz (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-03-31 gbranden StatusNeed Info Invalid
        Assigned toNone gbranden
        Open/ClosedOpen Closed
        Summary[PATCH] Troff outputs garbled file names on MS-Windows troff outputs garbled file names on MS Windows
    2023-03-30 gbranden Carbon-Copy- Added -email is unavailable-
    2020-10-21 gbranden StatusNone Need Info
    2020-10-13 barx Carbon-CopyRemoved 93119 -
    2020-10-13 barx SummaryTroff outputs garbled file names on MS-Windows [PATCH] Troff outputs garbled file names on MS-Windows
    2019-02-11 eliz Attached File- Added DIFFS_troff_backslashes, #46235

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code