Gene Heskett wrote:
sorry about the late rely here Kevin. The above example, except to -Plp3, has
been running for about 4 hours, and I have sent 11 copies of that directory
listing up the /dev/ttyUSB1 cable now with nothing going to that printer, or
when changed to lp1 which is right beside me. Neither that, nor a
cat /dev/ttyUSB1 | lp -d lp3 -
Gene, my reply was because someone quoted a command line using lpr, and
then someone else quoted a man page for lp. They are not the same
commands, at least not command option-wise.
From the line used above, it looks like you are trying to capture input
from a USB serial port and send it to a printer. Caution here! lp and
lpr are implemented by CUPS these days, and CUPS wants to do *lots* of
processing on the input before it actually sends it off to a physical
printer. It may in fact be waiting for either an EOF or a FF character,
since CUPS is probably paginating the input. It may even be waiting for
*all* of it before sending the processed result to the printer. That
would certainly explain the file you see in /tmp....
I can remember the days when printers were ASCII devices and would just
copy what was sent to them. Today, they are Postscript, or PCL, or
something else and it is more difficult to send text directly to them
and have it print out in real time.
works, both apparently doing exactly the same thing with the data, stuffing it
into a file in /tmp, which is not printed, and which is deleted if I ctl-c
the command line.
That has resulted in some activity I can see with htop, for both cat and lpr,
and there is now a file of some 105k in /tmp that contains these directory
listings. The tail end of this /tmp/file looks like this in text format:
[root@coyote tmp]# tail 482b58beea317
0 2008/05/13 21:00 --e-rewr 6B08 1B01 ed
0 2006/04/21 13:38 --e-rewr 1EF6C 16C wcreate
0 2006/04/21 13:38 --e-rewr 1EF70 439 xmode
0 2008/05/12 13:05 ------wr BFF4 211 GSort
0 2008/05/13 21:54 --e-rewr 3FF0 4EA noautoex
0 2008/05/13 21:09 --e-rewr FEDC 4EA multivue
0 1995/04/30 16:30 ----rewr FFF8 39BF GShell
0 1987/09/29 19:27 --e-rewr 1ECAC 3A6E Control
0 1988/02/19 20:02 --e-rewr 1ECB4 1DE compare
And in hexdump -C format:
00003c20 38 20 20 20 20 20 20 33 39 42 46 20 47 53 68 65 |8 39BF GShe|
00003c30 6c 6c 0a 20 20 20 30 20 20 31 39 38 37 2f 30 39 |ll. 0 1987/09|
00003c40 2f 32 39 20 31 39 3a 32 37 20 20 2d 2d 65 2d 72 |/29 19:27 --e-r|
00003c50 65 77 72 20 20 20 31 45 43 41 43 20 20 20 20 20 |ewr 1ECAC |
00003c60 20 33 41 36 45 20 43 6f 6e 74 72 6f 6c 0a 20 20 | 3A6E Control. |
00003c70 20 30 20 20 31 39 38 38 2f 30 32 2f 31 39 20 32 | 0 1988/02/19 2|
00003c80 30 3a 30 32 20 20 2d 2d 65 2d 72 65 77 72 20 20 |0:02 --e-rewr |
00003c90 20 31 45 43 42 34 20 20 20 20 20 20 20 31 44 45 | 1ECB4 1DE|
00003ca0 20 63 6f 6d 70 61 72 65 0a 0a 1b | compare...|
perhaps there is a clue here, like some control character missing?
As the src machine is not sending \n's, only \r's, /dev/ttyUSB1 is set to
translate \r's to \n's with stty options.
Does it need an EOF ($1B) to trigger the actual printing? I'm not sure I can
make the src machine do that, but I'll try. Yes, I could, but as a separate
line of the program and it shows in the above hexdump. As a test its ok, but
for day to day operations it would be a dud.
My guess is that it meeds an EOF to close the input stream and start
processing the output to the printer. YMMV
lpr is the owner of this file according to "lsof|grep lpr":
lpr 3533 root 4u REG 8,3 15531
82903079 /tmp/482b9fa495624
And just now, switching screens, I locked the machine up tight and had to hit
the reset button. 6 day uptime for 2.6.26-rc1 wrecked.
Perhaps the trigger for lpr to actually print it is some other control
character? I'm bumfuzzled to be sure, 2 days of screwing with this.
Many thanks, to Kevin J. Cummings, or anyone else who can shed some light on
this.
I'm not sure I have a definitive answer for you. I wish I did!
Good Luck!
--
Kevin J. Cummings
kjchome@xxxxxxx
cummings@xxxxxxxxxxxxxxxxxx
cummings@xxxxxxxxxxxxxxxxxxxxxxx
Registered Linux User #1232 (http://counter.li.org)
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
