Mail Archives: cygwin/2003/05/13/09:53:37
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 réseau non valide.
$ lpr -P \\\\\\\\mimosa\\\\glaieul gettime.c
lpr: can't open '\\\\mimosa\\glaieul' for writing
lpr: Adresse réseau non valide.
Adresse réseau non valide => Invalid network adresse
$ lpr -P \\\\mimosa\\glaieul gettime.c
lpr: StartDocPrinter error
lpr: Le type de donnée spécifié n'est pas valide.
$ lpr -P '\\mimosa\glaieul' gettime.c
lpr: StartDocPrinter error
lpr: Le type de donnée spécifié n'est pas valide.
Le type de donnée spécifié n'est pas valide => Invalid data type
So i don't know what append.
>>$ 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.
>
>
>>As shown by cygcheck, all the drives are mount in binmode.
>>
>>C:\cygwin / system binmode
>>C:\cygwin/bin /usr/bin system binmode
>>C:\cygwin/lib /usr/lib system binmode
>>C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode
>>. /cygdrive system binmode,cygdrive
>>
>>Lpr lives in /usr/bin/lpr.exe and I don't know where it comes from.
>>
>>Gilles
>
>
> That lpr comes from cygutils, but even the windows one should work in this
> case.
> Igor
Windows's lpr need both -P and -S to be specified, and doesn't support
pipes, only files. That's the why of my initial dirty hack.
Regards.
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/
- Raw text -