While i am executing a perl script in that one file will get as ouput in that ^M is priting and the actual output is getting disabled?

himanshu.chauhan has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: While i am executing a perl script in that one file will get as ouput in that ^M is priting and the actual output is getting disabled? by marto (Cardinal) on Apr 01, 2022 at 07:21 UTC
Carriage_return: `$str =~ s/\r//g;` [download]	[reply] [d/l]
Re^2: While i am executing a perl script in that one file will get as ouput in that ^M is priting and the actual output is getting disabled? by cavac (Prior) on Apr 04, 2022 at 08:52 UTC
As stated in the WIkipedia article (but not properly elaborated on): The reason that carriage return and linefeed are two different characters is mechanical constraints: On old Teletype (TTY) machines it takes about the time of two transmitted characters for the carriage to return to the starting position, but only one to advance the paper one line. So the encoding allows for the additional time requirement by always requiring to send carriage return first, followed by a linefeed. This provides that characters can be send non-stop at maximum (45 Baud) speed in normal use (for example using a paper tape as source). While still giving the option of using CR and LF separately for specific purposes (CR alone for overwriting a line, LF alone as sort of vertical tabulator). CuriousMarc has a nice demonstration of these early mechanical teletypes on his Youtube channel. Cynic me suspects these work about the same speed as a modern Windows cmd.exe, which is why Windows still uses CR+LF ;-) `perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'`	[reply] [d/l]
Re: While i am executing a perl script in that one file will get as ouput in that ^M is priting and the actual output is getting disabled? by BillKSmith (Monsignor) on Apr 02, 2022 at 22:52 UTC
Are you reading a file that was created with windows? Perl on windows translates the crlf line separators to "\n" (Removes the ^M) as it reads the file. You can do the same thing on other systems by specifying the crlf "layer" on your open statement or with binmode. The following code demonstrates that each line is read with the newline, but without the carriage return. `use strict; use warnings; use Test::More tests=>4; my $windows_file = "abc". "\r\n" ."def". "\r\n" ."ghi". "\r\n" ; my $in_file = \$windows_file; my $string; open my $fh, "<:crlf", $in_file; $string = <$fh>; ok( $string eq "abc\n", "line 1" ); $string = <$fh>; ok( $string eq "def\n", "line 2" ); $string = <$fh>; ok( $string eq "ghi\n", "line 3" ); ok( eof($fh), "end-of-file");` [download] Bill	[reply] [d/l]
Re: While i am executing a perl script in that one file will get as ouput in that ^M is priting and the actual output is getting disabled? by graff (Chancellor) on Apr 03, 2022 at 18:33 UTC
My runtime environment is always nix, so for me, perl's default "chomp" behavior is to remove just a final "\n". When I'm writing a script that might need to handle text files from both nix (LF) and ms-windows (CRLF), I use the following instead of chomp: `s/[\r\n]+$//` [download] Because I use macosx a lot, I also sometimes see text files that use just CR instead of LF. Then there are cases where a file isn't consistent in terms of its CR vs. LF vs. CRLF behavior, or where a file wasn't originally text data, but has been mishandled (corrupted by a "unix-to-dos" text-mode conversion as if it were text). It can get pretty maddening, so I wrote a script just to report diagnostics, and posted it here in a SoPW thread several years ago: Re: How to determine type of line endings in a text file from within a script It boils down to the problem of getting to know the data you're dealing with, and taking appropriate steps to give it the treatment it needs.	[reply] [d/l]