> Date: Sat, 08 Nov 2014 11:22:58 +0200 > From: Eli Zaretskii <e...@gnu.org> > > I think I know the reason. This is Windows-specific, as demonstrated > by using the -V switch: > > groff -t -man -V \usr\share\man\man1\chem.1 > tbl '\usr\share\man\man1\chem.1' | troff -man -Tascii | grotty > > The problem is triggered by using the backslash as directory separator > in file names (so the command I showed in my original report was a > lie ;-), which causes append_arg_to_string to try quoting the file name, > by using the '..' style of quoting. But native Windows programs don't > understand this quoting, so the quote characters are not stripped and > appear verbatim in the tbl command line. > > I will submit a change to fix this.
OK, there's more to this than just the quoting. I fixed the quoting, but I still see error messages, like this one: groff -t -man man\man1\chem.1 > man\cat1\chem.1 <standard input>:4: name expected (got a node): treated as missing <standard input>:0: warning: numeric expression expected (got `a') <standard input>:550: name expected (got a node): treated as missing <standard input>:410: warning: numeric expression expected (got `a') These come from the .lf directives, like this one: .lf 1 man\man1\chem.1 One possible solution to this is to convert all backslashes to forward slashes '/' when writing the .lf directive. Unfortunately, there are quite a few places where .lf is emitted, so before I go ahead and do it, I have a question: why do the programs that read those .lf directives choke on such file names? The Groff manual clearly says that the format of the .lf directive is .lf line [filename] So the programs who read this ought to interpret what follows the line number as a file name. Why do they try to interpret that as something else, like node or whatever? What am I missing here? TIA
