CR/LF 
Author Message
 CR/LF

Greetings,

I am assuming \r translates directly to CR, but does \n always translate to
LF? Or does it translate to LF on Unix, CR on Mac, CRLF on Windows? Is it
identical in behavior to C's \n escape?

sh



Thu, 26 Feb 2004 08:39:46 GMT  
 CR/LF

Quote:
> Greetings,

> I am assuming \r translates directly to CR, but does \n always translate to
> LF? Or does it translate to LF on Unix, CR on Mac, CRLF on Windows? Is it
> identical in behavior to C's \n escape?

The perlport manpage discusses '\n' as the "logical" newline, silently
converting to and from whatever it should be, usually intelligently
enough.  OTOH, as perlport says, \n cannot always be trusted.  If the
actual value of \n is important or even in question, it's possible you
should specify explicitly what you want. ("\012" for newline, "\015" for
carriage-return).

see `perldoc perlport` for more details, and some modules which provide
tools for making working with this concept easier (and more
maintainable). ;)

--
Watch my captor grow old and die.
No satisfaction. Still here.
    -- Morpheus, The Sandman



Thu, 26 Feb 2004 10:25:54 GMT  
 CR/LF

Quote:

>I am assuming \r translates directly to CR, but does \n always translate to
>LF? Or does it translate to LF on Unix, CR on Mac, CRLF on Windows? Is it
>identical in behavior to C's \n escape?

Er... Sort of.

In perl, "\n" is always one character, representing the newline. "\r" is
the other character.

In fact, on Unix, DOS and Windows (and similar, such as OS/2), "\n" is
chr(10)="\x0A"="\012". So "\r" is "\x0D"="\015".

Only when printing such a string to a text file (no binmode), on
DOS/Windows, "\n"/"\x0A" gets converted to the"\x0A\x0D" sequence, and
vice versa when reading from a text file.

On a Mac, a plain end of line ("\n") is a bare return, "\x0D", thus "\r"
is "\x0A". So the value of "\n" and "\r" got swapped.

But you use "\n" for the same purpose on Mac and the others: as the line
end marker. You shouldn't really be using "\r" in portable code.

--
        Bart.



Thu, 26 Feb 2004 11:31:58 GMT  
 CR/LF
On Sep 9, Tim Hammerquist inscribed on the eternal scroll:

Quote:

> > Greetings,

> > I am assuming \r translates directly to CR, but does \n always translate to
> > LF? Or does it translate to LF on Unix, CR on Mac, CRLF on Windows? Is it
> > identical in behavior to C's \n escape?

> The perlport manpage discusses '\n' as the "logical" newline, silently
> converting to and from whatever it should be, usually intelligently
> enough.  OTOH, as perlport says, \n cannot always be trusted.

                                      ^^^^^^^^^^^^^^^^^^^^^^^^

I suggest that may have been an unfortunate choice of terms: the
string "trust" doesn't appear anywhere in the copy of perlport that
I'm looking at - though I think I see what you're getting at.  You can
perfectly well _trust_ Perl to behave to specification on this issue:
the important thing is to know what that specification says ;-)

Older versions of Perl documentation showed unfortunate signs in this
area of having been composed by unix bigots.  But recent versions are
more even-handed in this regard.  Unix is quite able to demonstrate
its superiority without any need for bigotry ;-))  - and since Perl
rightly stresses benefits of portability, its documentation clearly
needs to reflect that fact.

Quote:
> If the
> actual value of \n is important or even in question, it's possible you
> should specify explicitly what you want. ("\012" for newline, "\015" for
> carriage-return).

Indeed.  And as a general rule, if you're working with \n and \r then
you want to open in text mode, whereas if you're working with \012 and
\015 then you want to open with binmode().  However, it's better to
understand what one's doing and why (based for example on that perldoc
perlport page), in preference to applying "as a general rule"
recipes by rote.  IMHO, of course.

good luck



Thu, 26 Feb 2004 13:35:10 GMT  
 CR/LF
On Sun, 09 Sep 2001 10:31:58 GMT,

Quote:

> But you use "\n" for the same purpose on Mac and the others: as the line
> end marker. You shouldn't really be using "\r" in portable code.

That is, if you are writing files. If you want to write portable code
that implements many of the RFC protocols, for example, then you
should never use \n, but always specifically the characters that are
proscribed by the protocol. In many cases that is \015\012 for an
"end-of-line". Not \r\n or simply \n, although both might work correctly
on some (different) platforms.

Unix ttys also have some special dealing with these things.

Martien
--
Martien Verbruggen              |
Interactive Media Division      | Useful Statistic: 75% of the people
Commercial Dynamics Pty. Ltd.   | make up 3/4 of the population.
NSW, Australia                  |



Thu, 26 Feb 2004 14:07:34 GMT  
 CR/LF

Quote:
> On Sep 9, Tim Hammerquist inscribed on the eternal scroll:


> > > Greetings,

> > > I am assuming \r translates directly to CR, but does \n always translate to
> > > LF? Or does it translate to LF on Unix, CR on Mac, CRLF on Windows? Is it
> > > identical in behavior to C's \n escape?

> > The perlport manpage discusses '\n' as the "logical" newline, silently
> > converting to and from whatever it should be, usually intelligently
> > enough.  OTOH, as perlport says, \n cannot always be trusted.
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^
> I suggest that may have been an unfortunate choice of terms: the
> string "trust" doesn't appear anywhere in the copy of perlport that
> I'm looking at - though I think I see what you're getting at.  You can
> perfectly well _trust_ Perl to behave to specification on this issue:
> the important thing is to know what that specification says ;-)

You're correct re. the POD that came with my 5.6.1 dist.  I regret that
my paraphrasing is not always what it should be.

Quote:
> Older versions of Perl documentation showed unfortunate signs in this
> area of having been composed by unix bigots.  But recent versions are
> more even-handed in this regard.  Unix is quite able to demonstrate
> its superiority without any need for bigotry ;-))  - and since Perl
> rightly stresses benefits of portability, its documentation clearly
> needs to reflect that fact.

Very well put. =)

Quote:
> > If the
> > actual value of \n is important or even in question, it's possible you
> > should specify explicitly what you want. ("\012" for newline, "\015" for
> > carriage-return).

> Indeed.  And as a general rule, if you're working with \n and \r then
> you want to open in text mode, whereas if you're working with \012 and
> \015 then you want to open with binmode().  However, it's better to
> understand what one's doing and why (based for example on that perldoc
> perlport page), in preference to applying "as a general rule"
> recipes by rote.  IMHO, of course.

> good luck

--
It is a fool's prerogative to utter
truths that no one else will speak.
    -- Morpheus, The Sandman


Thu, 26 Feb 2004 20:45:26 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Converting LF to CR+LF

2. DOS Perl convering LF to CR/LF

3. $/ = CR LF?

4. <FILE> and CR-LF

5. Binary data and CR-LF's in MSDOS

6. how to remove cr/lf ???

7. Question about formatting/(CR/LF) in PERL

8. Perl and CR+LF

9. CR LF to <br> in REGEX

10. CR/LF from a form

11. unwanted CR/LF translation in FILE UPLOAD

12. split function on CR/LF

 

 
Powered by phpBB® Forum Software