Re: [Groff] Strange error messages from Groff 1.22.3

[Eli Zaretskii]

> Date: Mon, 10 Nov 2014 19:08:00 +0000
> From: Ralph Corderoy <address@hidden>
> 
> One thing I think I've missed:  why has this come to light now?

Because I make a point of investigating any strange messages from the
program, while those who came before me didn't?

To put this in context, I bumped into this when producing the
formatted man pages for Groff, for which I run the following Windows
shell command:

  for %f in (share\man\man1\*.1) do make_cat %f

(where make_cat is a script that runs 'grog' and then applies the
command suggested by 'grog' to the file).  Since this uses cmd.exe
features, it must use backslashes.  When I ran this, I saw that many
formatting commands that caused Groff to run a pipe emitted those
strange messages.  Then I tried something like

  groff -t -man -Tascii share\man\man1\tbl.1

and saw the same messages.  So I looked into the source that produces
these messages, and the rest is history.

> Is groff running on Windows in a new manner?

No, AFAICS this problem was always there.  It just went unreported,
and possibly also undetected.

> Am I right in thinking that Windows' API is as happy with a/b/c as
> a\b\c

That's correct.

> and so wrappers around the code that's cooking up the a\b\c in the
> first place could transliterate there without caring where the a/b/c
> is later to be used?

The problem with this approach is that these file names are not cooked
by Groff code, they come from the command-line arguments typed by the
user, see above.  And AFAIK the (very cool, IMO) feature of
controlling how the user types the command line is not yet in Groff ;-).