This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: a2ps and printer
Igor Pechtchanski wrote:
On Tue, 13 May 2003, gilles civario wrote:
Igor Pechtchanski wrote:
On Tue, 13 May 2003, gilles civario wrote:
Gilles,
I'm getting the same message ("lpr: The printer name is invalid") for the
//server/printer syntax. However, I've just verified that the
'\\\\server\\printer' syntax works for me (i.e., use backslashes, and
escape them *twice*). Hope this helps,
Igor
Igor,
I'd checked this syntax too. And the anther is :
$ file gettime.c
gettime.c: ASCII C program text
$ lpr -P \\\\mimosa\\glaieul gettime.c
lpr: StartDocPrinter error
lpr: Le type de donne spcifi n'est pas valide.
Gilles,
No, no, no. You didn't read what I said carefully. I said the
backslashes have to be escaped *twice*! You missed the single quotes.
The correct syntax would be
$ lpr -P '\\\\mimosa\\glaieul' gettime.c
(note the quotes). That's what worked for me, and should work for you as
well. Alternatively,
$ lpr -P \\\\\\\\mimosa\\\\glaieul gettime.c
should also work.
Yes, I'd well read you, but here are the results :
$ lpr -P '\\\\mimosa\\glaieul' gettime.c
lpr: can't open '\\\\mimosa\\glaieul' for writing
lpr: Adresse rseau non valide.
$ lpr -P \\\\\\\\mimosa\\\\glaieul gettime.c
lpr: can't open '\\\\mimosa\\glaieul' for writing
lpr: Adresse rseau non valide.
Adresse rseau non valide => Invalid network adresse
$ lpr -P \\\\mimosa\\glaieul gettime.c
lpr: StartDocPrinter error
lpr: Le type de donne spcifi n'est pas valide.
$ lpr -P '\\mimosa\glaieul' gettime.c
lpr: StartDocPrinter error
lpr: Le type de donne spcifi n'est pas valide.
Le type de donne spcifi n'est pas valide => Invalid data type
So i don't know what append.
Gilles,
I have to apologize. The initial message contained the syntax for a2ps,
which does need additional escapes. For lpr itself you don't need to
escape the backslashes twice, so your syntax ('\\mimosa\glaieul' or
\\\\mimosa\\glaieul) should work. Sorry for the misunderstanding.
Why not try initially to just
$ echo Testing^L | lpr -P '\\mimosa\glaieul'
? (The ^L is the actual Ctrl-L character, you can escape it with Ctrl-V
in bash).
$ unix2dos gettime.c
gettime.c: done.
$ file gettime.c
gettime.c: ASCII C program text, with CRLF line terminators
$ lpr -P \\\\mimosa\\glaieul gettime.c
lpr: StartDocPrinter error
lpr: Le type de donne spcifi n'est pas valide.
While tracing the process with strace, I seen this :
295 107178 [main] lpr 1428 fhandler_disk_file::open: 1 = fhandler_disk_file::open (d:\civario\tmp\gettime.c, 0x0)
293 107471 [main] lpr 1428 open: 3 = open (gettime.c, 0x0)
231 107702 [main] lpr 1428 _cygwin_istext_for_stdio: _cygwin_istext_for_stdio (3)
231 107933 [main] lpr 1428 _cygwin_istext_for_stdio: _cifs: get_*_binary
3195 111128 [main] lpr 1428 writev: writev (2, 0x22E420, 1)
400 111528 [main] lpr 1428 fhandler_console::write: 22E4B0, 5
245 111773 [main] lpr 1428 fhandler_console::write: at 108(l) state is 0
lpr: 347 112120 [main] lpr 1428 fhandler_console::write: 5 = write_console (,..5)
254 112374 [main] lpr 1428 writev: 5 = write (2, 0x22E420, 1), errno 0
248 112622 [main] lpr 1428 writev: writev (2, 0x22E440, 1)
236 112858 [main] lpr 1428 fhandler_console::write: 22E4D0, 21
225 113083 [main] lpr 1428 fhandler_console::write: at 83(S) state is 0
StartDocPrinter error 310 113393 [main] lpr 1428 fhandler_console::write: 21 = write_console (,..21)
I think (but I may be wrong) that the text file is seen as a
binary one by lpr.
That shouldn't matter. The lpr you're using is smart enough not to care
too much.
Actually, I've just tried the same command as you did, and it worked for
me, even when the file was in DOS mode... It even works if the file
contains accented characters (in comments). Strange...
Is your printer a postscript printer? What is the driver? What OS are
you running?
My printer is a poscript printer, HP Laserjet 5SiMx.
The driver is the one provided by Windows as "HP Laserjet 5SI/5SI MX PS".
My os is Win2000 5.00.2195 SP2.
FYI, StartDocPrinter is a Windows function. That lpr implementation is
pretty simple-minded and sets the data type to "raw" unconditionally.
Perhaps your driver doesn't recognize it (or is case-sensitive on data
type specification)...
Since you can reproduce the problem, the best thing to try (given time, of
course) would be for you to download the source of the cygutils package
(through setup.exe); first compile lpr and see if it works, and then try
to tweak little things (like the case of the datatype specification, or
setting pOutputFile to NULL instead of "", as recommended by MSDN). For
reference, here's the relevant MSDN page:
<http://msdn.microsoft.com/library/en-us/gdi/prntspol_33n6.asp>. You
could then contribute a patch (against the original sources) back to the
project.
Igor
Igor.
Excellent idea. I've download the lpr sources and change the di1.pDatatype
from "raw" to "RAW"... Miracle, it's work perfectly !
As the StartDocPrinter error message were saying, the data type was incorect.
Here is the output of a uname -a on my machine :
$ uname -a
CYGWIN_NT-5.0 hepatique 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin
And here is the diff betwwen the two lpr.c files :
$ diff -urN lpr.c.orig lpr.c
--- lpr.c.orig 2002-03-03 04:09:42.000000000 +0100
+++ lpr.c 2003-05-14 07:27:22.000000000 +0200
@@ -110,7 +110,7 @@
di1.pDocName = docName;
di1.pOutputFile = "";
- di1.pDatatype = "raw";
+ di1.pDatatype = "RAW";
if (StartDocPrinter(deviceHandle, 1, (LPBYTE) &di1) == 0)
exitCode = error(1, "StartDocPrinter error");
Thanks a lot for the help.
Gilles.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/