Re: Doubt in code - Beginner in perl

We seldom have line-ending problems except when we prepare our input on a different operating system than we use to run our perl. Unless we explicitly specify otherwise, perl assumes that our data uses the line endings of the system that it is running under. Perl calls the appropriate IO-Layer to translate those line endings into perl newlines. (The fact that they are the same as the newline character in UNIX files really does not make any difference). If we try to read windows (CRLF) data under UNIX, the CR will be 'translated' to a perl newline. The LF is not translated at all. It is stored as an ordinary character (the first character of the next line - chomp does not see it at all). On output, the perl newline is 'translated' into a UNIX newline (CR). The LF (when present) is output as the first character of the next line (when it is output). This problem can be solved by specifying IO-Layers. Unfortunately, this is not a beginners topic. For now, just be aware of what is happening.

Sorry, My explanation (italic) is hopelessly confused.

Bill

Comment on Re: Doubt in code - Beginner in perl

Replies are listed 'Best First'.
Re^2: Doubt in code - Beginner in perl by haukex (Archbishop) on Dec 27, 2018 at 15:17 UTC
Sorry, but: If we try to read windows (CRLF) data under UNIX, the CR will be 'translated' to a perl newline. The LF is not translated at all. This makes it sound like the CR gets translated into some other character that is then present in the Perl string alongside the LF, which is not the case. From PerlIO in regards to the `:crlf` layer: On read converts pairs of CR,LF to a single "\n" newline character. On write converts each "\n" to a CR,LF pair. It is stored as an ordinary character (the first character of the next line - chomp does not see it at all). This is incorrect, the `"\n"` is stored at the end of the current line and removed by chomp (because $/ defaults to `"\n"`). On output, the perl newline is 'translated' into a UNIX newline (CR). The NIX newline is LF, not CR. The LF (when present) is output as the first character of the next line (when it is output).* This doesn't make sense to me. The newline is output whenever we tell Perl to output it, typically at the end of the current line, either explicitly or implicitly via $\.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Doubt in code - Beginner in perl
by haukex (Archbishop) on Dec 27, 2018 at 15:17 UTC

Sorry, but:

If we try to read windows (CRLF) data under UNIX, the CR will be 'translated' to a perl newline. The LF is not translated at all.

This makes it sound like the CR gets translated into some other character that is then present in the Perl string alongside the LF, which is not the case. From PerlIO in regards to the :crlf layer:

On read converts pairs of CR,LF to a single "\n" newline character. On write converts each "\n" to a CR,LF pair.

It is stored as an ordinary character (the first character of the next line - chomp does not see it at all).

This is incorrect, the "\n" is stored at the end of the current line and removed by chomp (because $/ defaults to "\n").

On output, the perl newline is 'translated' into a UNIX newline (CR).

The *NIX newline is LF, not CR.

The LF (when present) is output as the first character of the next line (when it is output).

This doesn't make sense to me. The newline is output whenever we tell Perl to output it, typically at the end of the current line, either explicitly or implicitly via $\.

[reply]
[d/l]
[select]