Newlines on Windows

[Guest]

I thought that on Windows, if you want to output a carriage return,
you have to use \r\n instead of just \n. So in my perl script that
generates a file, I put a \r\n after every line, but when I open the
file in an editor, I see a ^M after each line. This is with
ActivePerl 5.8.8.

 

[Chris Haffenstedt]

I thought that on Windows, if you want to output a carriage return,
you have to use \r\n instead of just \n.

So it's like in PHP. In Perl you haven't to do so. Just use \n and Perl
takes care for the rest, on Windows, Linux, Macintosh and all the rest.

 

[Jürgen Exner]

I thought that on Windows, if you want to output a carriage return,
you have to use \r\n instead of just \n.

Neither nor. You are confusing two different layers.

To output a carriage return you have to print the ASCII controll
character 13 (DEZ) or 0x0D (HEX) or short "\r". That is by definition
the CR character for ASCII which in turn is a subset of Windows-1252,
ISO-Latin-1, and many other encodings.

"\n" on the other hand in Perl is a logical line end, which will be
translated automatically into the correct line end sequence for the
current OS, be it 0x0A for unixoide OSes, 0x0A 0x0D for Windows, or 0x0D
for Mac.

So your combination \r\n on Windows will result in 0x0D 0X0A 0x0D.
Probably not what you want.

So in my perl script that
generates a file, I put a \r\n after every line, but when I open the
file in an editor, I see a ^M after each line. This is with

Well, you got what you added.

jue

 

[Guest]

Neither nor. You are confusing two different layers.

To output a carriage return you have to print the ASCII controll
character 13 (DEZ) or 0x0D (HEX) or short "\r". That is by definition
the CR character for ASCII which in turn is a subset of Windows-1252,
ISO-Latin-1, and many other encodings.

"\n" on the other hand in Perl is a logical line end, which will be
translated automatically into the correct line end sequence for the
current OS, be it 0x0A for unixoide OSes, 0x0A 0x0D for Windows, or 0x0D
for Mac.

So your combination \r\n on Windows will result in 0x0D 0X0A 0x0D.
Probably not what you want.


Well, you got what you added.

jue

Thanks for the explanation.

 

[Tim Greer]

I thought that on Windows, if you want to output a carriage return,
you have to use \r\n instead of just \n. So in my perl script that
generates a file, I put a \r\n after every line, but when I open the
file in an editor, I see a ^M after each line. This is with
ActivePerl 5.8.8.

This is an issue with what you use to edit the file. It's inserting
hidden line feed characters (junk) in the script.

 

[Bjoern Hoehrmann]

* (e-mail address removed) wrote in comp.lang.perl.misc:

I thought that on Windows, if you want to output a carriage return,
you have to use \r\n instead of just \n. So in my perl script that
generates a file, I put a \r\n after every line, but when I open the
file in an editor, I see a ^M after each line. This is with
ActivePerl 5.8.8.

See `perldoc perlport` for an in-depth discussion of line endings.

 

[Peter J. Holzer]

Neither nor. You are confusing two different layers.

To output a carriage return you have to print the ASCII controll
character 13 (DEZ) or 0x0D (HEX) or short "\r". That is by definition
the CR character for ASCII which in turn is a subset of Windows-1252,
ISO-Latin-1, and many other encodings.

"\n" on the other hand in Perl is a logical line end, which will be
translated automatically into the correct line end sequence for the
current OS, be it 0x0A for unixoide OSes, 0x0A 0x0D for Windows, or 0x0D
for Mac.

So your combination \r\n on Windows will result in 0x0D 0X0A 0x0D.
Probably not what you want.

[...]

Thanks for the explanation.

It is worth noting that the translation Jürgen talks about happens only
during file I/O. Inside of a perl script, "\n" is always a single
character ("\015" on old MacOS, "\012" on Unix, Windows, and (I think)
also on MacOS X). When writing to a file with the :crlf I/O layer enabled
(which is the default on Windows, but you can turn it off with binmode
or an argument to open), the single "\n" is converted to "\015\012". The
reverse conversion is done when reading a file with the :crlf layer.

(Perl can do other conversions on I/O, too, e.g., character set
conversions, compression, etc.)

hp

 

[Jürgen Exner]

It is worth noting that the translation Jürgen talks about happens only
during file I/O. Inside of a perl script, "\n" is always a single
character ("\015" on old MacOS, "\012" on Unix, Windows, and (I think)
also on MacOS X). When writing to a file with the :crlf I/O layer enabled
(which is the default on Windows, but you can turn it off with binmode
or an argument to open), the single "\n" is converted to "\015\012". The
reverse conversion is done when reading a file with the :crlf layer.

To be crystal clear on that: did you mean "writing to a file" or
"writing to a file handle"?
Like in writing to STDOUT, but having the shell redirect into a file?

jue

 

[Dr.Ruud]

Jürgen Exner schreef:

your combination \r\n on Windows will result in 0x0D 0X0A 0x0D.

On Windows, \n is CR-LF, not LF-CR.

 

[Peter J. Holzer]

To be crystal clear on that: did you mean "writing to a file" or
"writing to a file handle"?

File handle.

hp

 

[David Combs]

File handle.

hp

I'm a bit puzzled by your question, file or file-handle.

Suppose he'd answered "writing to a file".

How would your answer be different?

Thanks,

David

 

[Peter J. Holzer]

I'm a bit puzzled by your question, file or file-handle.

Suppose he'd answered "writing to a file".

How would your answer be different?

I'm not quite sure who you mean by "you" and "he". But anyway:

It is conceivable that perl behaves differently for file handles which
refer to files (i.e., byte streams stored on a random access medium such
as a disk) and file handles which refer to other objects (pipes,
sockets, terminals, ...). In fact, perl does make a similar distinction
for buffering (file handles referring to terminals are by default
line-buffered, file handles referring to sockets are unbuffered, and
everything else is block-buffered). However, for I/O layers there is no
such distinction - what I wrote is true for all kinds of file handles,
not just for file handles referring to files.

hp