Perl Guru Forums: Perl Programming Help: Advanced: issue with file captured by IO::Socket::INET

CGI/Perl Guide | Learning Center | Forums | Advertise | Login

Site Search: in


	MAIN INDEX	SEARCH POSTS	WHO'S ONLINE	LOG IN

Home: Perl Programming Help: Advanced:
issue with file captured by IO::Socket::INET

w00005414
New User

Oct 12, 2011, 1:54 PM

Post #1 of 7 (4141 views)

issue with file captured by IO::Socket::INET	Can't Post

Hi all,

I am trying to create a simple listener to receive print jobs from a Windows printer driver, I have the following code and it does capture the print job sent to it from the driver

use IO::Socket::INET;
$myport=5555;
$pserve=IO::Socket::INET->new(LocalPort => $myport,LocalAddr => 'localhost',Type=>SOCK_STREAM,Reuse=>1,Listen=>1) or die "can't do that $!\n";
while ($pjob=$pserve->accept()) {
open(J,">c:\\printtest") or print "having issues $!\n";
while (<$pjob>) {
print J "$_";
}
close J;

close $pjob;
}

When I set up the print queue as a "Local Port" and point it to a file that file might be 46 Bytes but when I point it to my Perl listener (set up as a standard TCP/IP printer connection) the same PCL formatted file will be 47 Bytes. If I use lpr to send the 46 byte file it prints out fine, if I do the same with 47 Byte file my listener captured I get a PCL error..... when I look at the same 2 files in Notepad they look similar but there seems to be more spaces (or tabs, not sure) in the file created by my listener.

Any suggestions?

rovf
Veteran

Oct 14, 2011, 1:25 AM

Post #2 of 7 (4120 views)

Re: [w00005414] issue with file captured by IO::Socket::INET [In reply to]	Can't Post

Quote

Any suggestions?

Don't look at the file with Notepad.

Look at it with a Hex-Viewer.

w00005414
New User

Oct 14, 2011, 12:29 PM

Post #3 of 7 (4107 views)

Re: [rovf] issue with file captured by IO::Socket::INET [In reply to]	Can't Post

Hi rovf,

When I compare the files within Binary Viewer it looks like the file with issues gets an extra Hex value of "OD" thrown in there which corresponds to the ascii "." value I believe. I've attached the 2 files and I added .txt to them so they will upload.

Thanks for any help you can possibly provide

Attachments:

willprint.txt (45.1 KB)

wontprint.txt (45.1 KB)

rovf
Veteran

Oct 17, 2011, 12:48 AM

Post #4 of 7 (3878 views)

Re: [w00005414] issue with file captured by IO::Socket::INET [In reply to]	Can't Post

0D doesn't correspond to '.', but to carriage return. I see that your "corrupt" file contains the sequence 0D0D0A.

It seems that a 0A is translated into 0D0A, and since the original file already has 0D0A, this becomes 0D0D0A, which is, as you rightly noticed, one 0D too many.

Now this type of transformation is something I could imagine to happen only at the sender side, not at the side where you are listening to the socket. Can you check the code there?

w00005414
New User

Oct 17, 2011, 6:48 AM

Post #5 of 7 (3835 views)

Re: [rovf] issue with file captured by IO::Socket::INET [In reply to]	Can't Post

hi rovf,

Thanks for taking a look at the two files., unfortunately I do not have control over how the client sends the file, it is the Windows printer spooler service that is sending the job. I only have 2 options when sending, RAW format (which is what I am using) or the LPR protocol. When I try the LPR protocol it never successfully sends the file so I don't think that is an option either. Frown

rovf
Veteran

Oct 17, 2011, 7:58 AM

Post #6 of 7 (3824 views)

Re: [w00005414] issue with file captured by IO::Socket::INET [In reply to]	Can't Post

I found something in perldoc perlipc, which could be related to your issue (it's in the section labelled "Sockets: Client/Server Communication"):

Quote

Internet Line Terminators
The Internet line terminator is "\015\012". Under ASCII variants of
Unix, that could usually be written as "\r\n", but under other systems,
"\r\n" might at times be "\015\015\012", "\012\012\015", or something
completely different. The standards specify writing "\015\012" to be
conformant (be strict in what you provide), but they also recommend
accepting a lone "\012" on input (but be lenient in what you require).
We haven't always been very good about that in the code in this manpage,
but unless you're on a Mac, you'll probably be ok.

Note that this explicitly mentions your case (\015\015\012). This means that it's pointless to think where the spurious 0D comes from, and you should, ideally, write your listener in a way that it accept all those line endings, including 0D0D0A, and convert them to a single \n (or what else you want to have as line ending).

w00005414
New User

Oct 17, 2011, 12:21 PM

Post #7 of 7 (3787 views)

Re: [rovf] issue with file captured by IO::Socket::INET [In reply to]	Can't Post

Hi rovf.... thanks for finding this, I will investigate!

Search for (options)

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives