IO::Socket 
Author Message
 IO::Socket

hello,
I'm running Active Perl v5.0 on Windoze 98

I'm trying to write a script that contacts a webpage and downloads the
file contained on the webpage.  So far, everything is perfect, except
for the downloading..  The downlaoded file is stored in a file on the
hard drive, but it's has errors...i did a test using a webserver on my
own computer, and the resulting file i downloaded from it had many
errors compared to the origional.

Is there a way to specify binary, or did i code all that for nothing?

thx
lucas



Wed, 26 Jan 2005 14:01:34 GMT  
 IO::Socket
I think binmode() should do it:

  binmode FILEHANDLE, DISCIPLINE
  binmode FILEHANDLE
  Arranges for FILEHANDLE to be read or written in "binary" or "text" mode
on systems where the run-time libraries distinguish between binary and text
files. If FILEHANDLE is an expression, the value is taken as the name of the
filehandle. DISCIPLINE can be either of ":raw" for binary mode or ":crlf"
for "text" mode. If the DISCIPLINE is omitted, it defaults to ":raw".

  binmode() should be called after open() but before any I/O is done on the
filehandle.

  On many systems binmode() currently has no effect, but in future, it will
be extended to support user-defined input and output disciplines. On some
systems binmode() is necessary when you're not working with a text file. For
the sake of portability it is a good idea to always use it when appropriate,
and to never use it when it isn't appropriate.

  In other words: Regardless of platform, use binmode() on binary files, and
do not use binmode() on text files.

  The open pragma can be used to establish default disciplines. See open.

  The operating system, device drivers, C libraries, and Perl run-time
system all work together to let the programmer treat a single character (\n)
as the line terminator, irrespective of the external representation. On many
operating systems, the native text file representation matches the internal
representation, but on some platforms the external representation of \n is
made up of more than one character.

  Mac OS and all variants of Unix use a single character to end each line in
the external representation of text (even though that single character is
not necessarily the same across these platforms). Consequently binmode() has
no effect on these operating systems. In other systems like VMS, MS-DOS and
the various flavors of MS-Windows your program sees a \n as a simple \cJ,
but what's stored in text files are the two characters \cM\cJ. That means
that, if you don't use binmode() on these systems, \cM\cJ sequences on disk
will be converted to \n on input, and any \n in your program will be
converted back to \cM\cJ on output. This is what you want for text files,
but it can be disastrous for binary files.

  Another consequence of using binmode() (on some systems) is that special
end-of-file markers will be seen as part of the data stream. For systems
from the Microsoft family this means that if your binary data contains \cZ,
the I/O subsystem will regard it as the end of the file, unless you use
binmode().

  binmode() is not only important for readline() and print() operations, but
also when using read(), seek(), sysread(), syswrite() and tell() (see
perlport for more details). See the $/ and $\ variables in perlvar for how
to manually set your input and output line-termination sequences.

Quote:

> hello,
> I'm running Active Perl v5.0 on Windoze 98

> I'm trying to write a script that contacts a webpage and downloads the
> file contained on the webpage.  So far, everything is perfect, except
> for the downloading..  The downlaoded file is stored in a file on the
> hard drive, but it's has errors...i did a test using a webserver on my
> own computer, and the resulting file i downloaded from it had many
> errors compared to the origional.

> Is there a way to specify binary, or did i code all that for nothing?

> thx
> lucas



Wed, 26 Jan 2005 15:36:51 GMT  
 IO::Socket


Quote:
>I think binmode() should do it:

>  binmode FILEHANDLE, DISCIPLINE
>  binmode FILEHANDLE
>  Arranges for FILEHANDLE to be read or written in "binary" or "text" mode
>on systems where the run-time libraries distinguish between binary and text
>files. If FILEHANDLE is an expression, the value is taken as the name of the
>filehandle. DISCIPLINE can be either of ":raw" for binary mode or ":crlf"
>for "text" mode. If the DISCIPLINE is omitted, it defaults to ":raw".

>  binmode() should be called after open() but before any I/O is done on the
>filehandle.

>  On many systems binmode() currently has no effect, but in future, it will
>be extended to support user-defined input and output disciplines. On some
>systems binmode() is necessary when you're not working with a text file. For
>the sake of portability it is a good idea to always use it when appropriate,
>and to never use it when it isn't appropriate.

>  In other words: Regardless of platform, use binmode() on binary files, and
>do not use binmode() on text files.

>  The open pragma can be used to establish default disciplines. See open.

>  The operating system, device drivers, C libraries, and Perl run-time
>system all work together to let the programmer treat a single character (\n)
>as the line terminator, irrespective of the external representation. On many
>operating systems, the native text file representation matches the internal
>representation, but on some platforms the external representation of \n is
>made up of more than one character.

>  Mac OS and all variants of Unix use a single character to end each line in
>the external representation of text (even though that single character is
>not necessarily the same across these platforms). Consequently binmode() has
>no effect on these operating systems. In other systems like VMS, MS-DOS and
>the various flavors of MS-Windows your program sees a \n as a simple \cJ,
>but what's stored in text files are the two characters \cM\cJ. That means
>that, if you don't use binmode() on these systems, \cM\cJ sequences on disk
>will be converted to \n on input, and any \n in your program will be
>converted back to \cM\cJ on output. This is what you want for text files,
>but it can be disastrous for binary files.

>  Another consequence of using binmode() (on some systems) is that special
>end-of-file markers will be seen as part of the data stream. For systems
>from the Microsoft family this means that if your binary data contains \cZ,
>the I/O subsystem will regard it as the end of the file, unless you use
>binmode().

>  binmode() is not only important for readline() and print() operations, but
>also when using read(), seek(), sysread(), syswrite() and tell() (see
>perlport for more details). See the $/ and $\ variables in perlvar for how
>to manually set your input and output line-termination sequences.

Thanks very much for your input.  It solved my problem beautifully ;)

lucas



Thu, 27 Jan 2005 02:52:27 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Proper way to close an IO::Socket or IO::Socket::INET

2. IO::Socket, IO::Select, and buffered/unbuffered IO

3. ActivePerl, Win2K, non-blocking, IO::Socket, IO::Select

4. question about io::socket & io:select

5. IO::Select and IO::Socket question: multiple connections

6. IO::Socket && IO::Select Problem

7. IO::Select and IO::Socket question: multiple connections

8. IO::Select and IO::Socket

9. IO::Socket / IO::Select Help...

10. IO::Socket::INET - reading from a socket?

11. Time out with perl Socket using IO::Socket

12. Help with creating UDP sockets using IO::Socket

 

 
Powered by phpBB® Forum Software