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 <[EMAIL PROTECTED]>
"What do we want? BRAINS! When do we want it? BRAINS!"
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);
