Hi charlie,
> we are more Windows knowledgeable.
Good, because I'm not and have investigated on Linux... :-)
> > grops:<standard input>:4:fatal error: fdopen: Invalid argument
I just did a simple
date | troff -Tps | grops >foo.ps
but with ltrace(1) monitoring grops so I could see what calls to
fdopen(3) occurred. There was only one.
mkstemp("/tmp/groffXXXXXX") = 3
fdopen(3, "w+") = 0x2149ed0
strlen("/tmp/groff4Jh8gU") = 16
The fdopen() is probably src/libs/libgroff/tmpfile.cpp's from its
xtmpfile().
FILE *xtmpfile(char **namep, const char *postfix_long,
const char *postfix_short, int do_unlink)
{
char *templ = xtmptemplate(postfix_long, postfix_short);
errno = 0;
int fd = mkstemp(templ);
if (fd < 0)
fatal("cannot create temporary file: %1", strerror(errno));
errno = 0;
FILE *fp = fdopen(fd, FOPEN_RWB); // many callers of xtmpfile use
binary I/O
if (!fp)
fatal("fdopen: %1", strerror(errno));
FOPEN_RWB is "w+" in my ltrace output but on Windows
src/include/nonposix.h makes me think it will be "wb+". It looks like a
mismatch between the mode used to open the temporary file and the mode
that's then used to map a FILE* onto it with fdopen.
groff provides its own mkstemp() if the platform doesn't and that
open(2)s it with `O_RDWR | O_CREAT | O_EXCL'. So either that's being
used and lacking the O_BINARY, that I think Windows defines, or Windows'
has a mkstemp that doesn't set `b' either.
Hope this helps those experienced with handling Windows's needs in the
groff source to cook up a solution.
--
Cheers, Ralph.
https://plus.google.com/115649437518703495227
