Bug#334450: Review of proposed stable changes

[Loic Minier]

        Hi,

On Tue, Oct 25, 2005, Martin Schulze wrote:
> If I understand the problem correctly, for some reason libgnomeprint does
> not use the proper lpr command.  However, the patch does not implicate
> the execution location.

 Actually, the problem is not the PATH or the availability of the lpr
 command, but simply a mistake in the arguments passed to popen(3).
 Linux' popen doesn't support the "b" flag which means "binary" under
 windows (windows doesn't assume binary by default).

 I'm sorry for having wasted your time with the first patch, attached is
 a clean patch which fixes only the flags passed to popen().  It is a
 one-liner.

 [ The first patch had 1/ a typo, 2/ the upstream fix which also takes
 care of keeping the "b" flag under Windows, 3/ intended to have an
 ifdef fix for Windows (#if !defined(HAVE_PCLOSE) instead of #if
 !defined(HAVE_CLOSE)). ]

 I also attach a test case showing that Linux popen fails with the "b"
 flag.

   Cheers,
-- 
Loïc Minier <lool at dooz.org>
"What do we want? BRAINS! When do we want it? BRAINS!"
-------------- next part --------------
diff -urN libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c
--- libgnomeprint-2.8.2.orig/libgnomeprint/transports/gp-transport-custom.c	2004-12-03 19:25:09.000000000 +0100
+++ libgnomeprint-2.8.2/libgnomeprint/transports/gp-transport-custom.c	2005-10-25 12:41:38.000000000 +0200
@@ -146,7 +146,7 @@
 		command = g_strdup ("lpr");
 	}
 
-	tcustom->pipe = popen (command, "wb");
+	tcustom->pipe = popen (command, "w");
 
 	if (tcustom->pipe == NULL) {
 		g_warning ("Opening '%s' for output failed", command);