#388 netpbm-10.27: pnmtopng.exe can't read from pipe

[Keith Marshall]

Building of GNU Troff (groff) from CVS sources requires execution of the command pipeline:

$ xpmtoppm ${top_srcdir}/doc/gnu.xpm | pnmdepth 15 | pnmtopng > gnu.png

When this is executed, with:

$ pnmtopng --version
d:\usr\local\bin\pnmtopng.exe: Using libnetpbm from Netpbm Version: Netpbm 10.27.0
d:\usr\local\bin\pnmtopng.exe: Compiled Thu May 12 09:47:16 CES 2005 by user "KZLG"
d:\usr\local\bin\pnmtopng.exe: BSD defined
d:\usr\local\bin\pnmtopng.exe: RGB_ENV='RGBDEF'
d:\usr\local\bin\pnmtopng.exe: RGBENV= 'RGBDEF' (env vbl is unset)

in an MSYS shell, I see:

$ xpmtoppm ${top_srcdir}/doc/gnu.xpm | pnmdepth 15 | pnmtopng > gnu.png
d:\usr\local\bin\pnmtopng.exe: Unable to create temporary file. mkstemp() failed with errno 22 (Invalid argument)
d:\usr\local\bin\pnmdepth.exe: Error writing single byte sample to file
d:\usr\local\bin\xpmtoppm.exe: Error writing single byte sample to file

Breaking the pipeline down into:

$ xpmtoppm ${top_srcdir}/doc/gnu.xpm | pnmdepth 15 > gnu.pnm

shows successful completion of this step, but then I see the same error with:

$ cat gnu.pnm | pnmtopng > gnu.png
d:\usr\local\bin\pnmtopng.exe: Unable to create temporary file. mkstemp() failed with errno 22 (Invalid argument)

but:

$ pnmtopng < gnu.pnm > gnu.png
d:\usr\local\bin\pnmtopng.exe: 14 colors found

appears to work, and gnu.png is created (7228 bytes, compared to zero bytes in the failing cases).

Reverting pnmtopng to an earlier release:

$ pnmtopng --version
d:\usr\local\bin\pnmtopng.exe: Using libpbm from Netpbm Version: Netpbm 10.6
d:\usr\local\bin\pnmtopng.exe: Compiled Sat Aug 3 18:49:55 2002 by user "Alpha"
d:\usr\local\bin\pnmtopng.exe: BSD defined
d:\usr\local\bin\pnmtopng.exe: RGB_ENV='RGBDEF'
d:\usr\local\bin\pnmtopng.exe: RGBENV= 'RGBDEF' (env vbl is unset)

eliminates the problem with the original pipeline, (although the generated png file is slightly larger, at 7260 bytes). (Another groff user has reported the same problem, and similar success on reverting to netpbm-10.18.4, with libpng-1.2.7, rather than libpng-1.2.8).

[Keith Marshall]

Logged In: YES
user_id=823908
Originator: YES

See also bug #1704410, which appears as if it may be related.

[GnuWin]

Logged In: YES
user_id=217802
Originator: NO

The command cat gnu.pnm | pnmtopng > gnu.png works well in an MS-Windows command shell. So
I think the failure under MSys is due to mixing the Msys bash shell with the native Win32 ports of Netpbm. Probably, TMPDIR, TMP or TEMP is defined in Msys as something like /c/temp, and this is not a valid path in a native program.
That this works with an older release of Netpbm is because the treatment of temporary files has changed: in older releases temporary files were created in the current directory, whereas in the present release they are created by means of mkstemp in the temporary-file directory pointed at by TMPDIR, TMP or TEMP.
I'll look further into this, and when indeed this is the problem, create a patch. But it will take some time before I can actually do this, and it will certainly not be done before November.

[Nobody/Anonymous]

MSYS command line argument viewer

[Keith Marshall]

Logged In: YES
user_id=823908
Originator: YES

File Added: showtemp.c

[Keith Marshall]

MSYS environment variable (TEMP) viewer

[Keith Marshall]

Logged In: YES
user_id=823908
Originator: YES

The command cat gnu.pnm | pnmtopng > gnu.png works well in an
MS-Windows command shell.

As, it appears, does the full original command pipeline.

I think the failure under MSys is due to mixing the Msys bash
shell with the native Win32 ports of Netpbm. Probably, TMPDIR,
TMP or TEMP is defined in Msys as something like /c/temp, and
this is not a valid path in a native program.

This is a red herring, as can be easily demonstrated by the two attached programs; (SF seemed to forget I was logged in, when I attached the first, and it threw away my text too; did I mention that I hate these web forms? :-( ). Compiling both with MinGW, and running them, all from within an MSYS shell session shows:--

$ gcc -o dumpargs.exe dumpargs.c

$ ./dumpargs "$TMP" "$TEMP" "$TMPDIR"
argv[0]: D:\usr\MSYS-1.0.11\home\rgbl0264\dumpargs.exe
argv[1]: C:/TEMP
argv[2]: C:/TEMP
argv[3]:

$ gcc -o showtemp.exe showtemp.c

$ ./showtemp
Environment variable 'TMP' is C:/TEMP
Environment variable 'TEMP' is C:/TEMP
Environment variable 'TMPDIR' is undefined

Notice how the command line arguments, and in particular the environment variables, when they represent MSYS style paths, are automatically transformed to valid native Woe32 format, before the native program gets to see them; (yes, C:/TEMP is a valid Woe32 path, and anyone who tries to tell you that it must be C:\TEMP is sadly misinformed).

For reference, in MSYS, these variables, as shown by the `echo' command, have values of:--

$ echo $TMP
/tmp

$ echo $TEMP
/tmp

$ echo $TMPDIR

$ _

(Note that TMP and TEMP both point to /tmp, which the MSYS fstab maps to C:\TEMP, while TMPDIR is not defined). Also, for the record, if I redefine these, and add an export for TMPDIR:--

$ TMP='C:\TEMP'
$ TEMP='C:\TEMP'
$ export TMPDIR='C:\TEMP'

so that all are now explicitly defined, and seen by showtemp, in definitively conventional Woe32 format:--

$ ./showtemp
Environment variable 'TMP' is C:\TEMP
Environment variable 'TEMP' is C:\TEMP
Environment variable 'TMPDIR' is C:\TEMP

that I still see the same failure:--

$ cd ~/src/groff-current

$ xpmtoppm doc/gnu.xpm | pnmdepth 15 | pnmtopng > gnu.png
d:\usr\local\bin\pnmtopng.exe: Unable to create temporary file. mkstemp() failed with errno 22 (Invalid argument)
d:\usr\local\bin\pnmdepth.exe: Error writing single byte sample to file
d:\usr\local\bin\xpmtoppm.exe: Error writing single byte sample to file

That this works with an older release of Netpbm is because the
treatment of temporary files has changed: in older releases
temporary files were created in the current directory, whereas
in the present release they are created by means of mkstemp in
the temporary-file directory pointed at by TMPDIR, TMP or TEMP.

Whatever. There is a problem somewhere, which between us, we need to fix. The diagnostic message points to your implementation of mkstemp; FWIW, you may find my own implementation, for MinGW, here: http://mingw.cvs.sourceforge.net/mingw/catgets/repl/mkstemp.c?view=annotate

This seems to work fine where I've used it, but YMMV. In any case, since your implementation appears to work fine in native cmd.exe, the problem must lie somewhere in the interaction with MSYS, and it would be good to understand just what is causing it. I'll file an associated bug report on the MinGW tracker, so we can also follow up from our end; between us, with a bit of luck, we should be able to resolve this.

[Keith Marshall]

Logged In: YES
user_id=823908
Originator: YES

FTR,

I'll file an associated bug report on the MinGW tracker,
so we can also follow up from our end; between us, with
a bit of luck, we should be able to resolve this.

https://sourceforge.net/tracker/index.php?func=detail&aid=1793180&group_id=2435&atid=102435