in reply to Re: Can anyone figure how this works?
in thread Can anyone figure how this works?

My only question is with regard to inplace edit. How does it function with regard to Binmode? Or has it been left out as it appears unneeded?

Slightly confused, :-)

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

  • Comment on Re: Re: Can anyone figure how this works?

Replies are listed 'Best First'.
Re: Re: Re: Can anyone figure how this works?
by tachyon (Chancellor) on Sep 30, 2001 at 22:10 UTC

    In unix the default line ending is a line feed LF (\n or \012 or 0xA). In DOSWin it is carriage return line feed CRLF (\r\n or \015\012 or 0xA0xD). On a Mac it is CR (\r or \015 0xD)

    When you read and write text files perl will automatically convert from its internal use of \012 for the line ending to whatever the system is using. On unix this means it does nothing, but on Mac and Windows conversions are made.

    Binmode tells perl not to convert line endings when reading or writing. In other words it does a raw read/write. On unix binmode has no effect as there is no conversion to make. On other systems the results are quite predictable.

    Perl uses \012 as the default line ending so if you binmode an output file handle such as STDOUT, $fh, etc and then print "blah \n"you will write \012. This will not be correctly recognised as a line ending on DOSWin or Mac when trying to read this file - this is true for any program including perl programs. Unix however, will read this file fine as will perl running under unix.

    When you binmode an input filehandle such as STDIN, $fh, etc you get a raw read. Thus on DOSWin if you read in a textfile under binmode you will see that the line ending is \r\n. Visually this appears a double spaced lines.

    How *your* script behaves is system dependent. When you read from a file you read one line at a time as defined by the default system line ending - internally this will be represented as \n Let's assume you have a file that has \r\n line endings. On unix you will get an internal file with \r\n because no conversion is done. Reading the same file under DOSWin will get an internal file with only \n line endings.

    With binmode on an output FH when you output \r\n that is what you get. With binmode off things will differ. On unix you will still get \r\n. On DOSWin you will get \r\r\n as the \n is converted to \r\n.

    Unless you are writing text files across systems you do not need to worry too much. If you need binmode on the inplace edit script just binmode STDOUT.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

      thanks tachyon, that was really elaborate.

      Now i know i made a mistake when extracting the file from SQL server itself as i took the data and printed it to a file using a perl program and it changed the \r\n to \r\r\n. I should have done binmode to the output before printing the data there itself.

      Thanks again.

      thesundayman

        Not sure that is actually right. Normally perl will handle line ending conversions automatically for you if you just leave binmode alone.

        Internally (in a perl program) you use \n as your symbol for a line ending and let perl handle the details - when you write a file the correct system line ending will be written and when you read a file the line endings will be converted to the internal \n. Sometimes the wheels fall off and you need to fix things manually but usually it all works beautifully.

        cheers

        tachyon

        s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print