Ralph, THANK YOU for your reply.
I have versions that *were* working prior to a reprovisioning of the 2008R2 Server. I have lousy install docs (this is my own fault) and after review of your trace results... I'm wondering if my issue is as simple as groff not being able to find the TEMP directory... I have created the following environment variables hoping that one would do the trick - but, no. TEMP=C:\TEMP TMP=C:\TEMP TMPDIR=C:\TEMP GROFF_TMPDIR=C:\TEMP I remember setting some variable (4+ years ago)... Is there a groff command line switch that would display what TEMP directory groff is using, else allow me to force one when I invoke groff? -charlie -----Original Message----- From: Ralph Corderoy [mailto:ra...@inputplus.co.uk] Sent: Wednesday, October 09, 2013 3:47 PM To: char...@vandien.com Cc: Tony Krier; groff@gnu.org Subject: Re: [Groff] need help resolving groff error 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
