> Date: Mon, 10 Nov 2014 19:08:00 +0000 > From: Ralph Corderoy <ra...@inputplus.co.uk> > > 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 ;-).
