in reply to Re: alter $/ - but why?
in thread alter $/ - but why?

Because of the first, the whole structure is kind of odd anyway, since with Mac line endings, you'd slurp the whole file to find out that you have those line endings.
Actually, if you set $/ = "\n" (which is the default), you only have a problem if you read files created by another OS. "\n" isn't a fixed byte - it's the appropriate bytesequence for the OS.

That's why print "$line\n" is the portable way of printing lines to (text)files, but the unportable way of writing to sockets that a protocol that uses CR/LF as its line terminator - as many popular protocols do. And printing "$line\r\n" is unportable as well - use print "$line\x0A\x0D".

Replies are listed 'Best First'.
Re^3: alter $/ - but why?
by radiantmatrix (Parson) on Aug 04, 2005 at 18:21 UTC

    If you are guaranteed to only read your OS's native formats, then you wouldn't need this routine at all. Therefore, I assumed the OP has this code in place because the script running on one OS is likely to read files created by several different OSes.

    So, I stand by my statement: if you read a file with Mac line endings (say, on a Unix box), using the code in the top node would read the whole file, since $/ would be looking for a Unix-style line-endings, which don't contain "\r";

    Your point about using the hex values for setting is a good one to remember, but the code as I wrote it automatically accounts for that. As for using the same line endings for output as have been determined for input, $\ = $/ is sufficient.

    <-radiant.matrix->
    Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law