I/O input is very tolerant about read (accepts any of the flavors of line ending and chomp operates fine). Perl I/O uses the context appropriate value for write. For example on Unix, printing to a file gives just <LF>, on Windows printing to a file give <CR><LF> and printing to a socket (any OS) gives <CR><LF> - the network standard text line ending.
The "\n" here may be just matching <LF>(Line Feed) instead of <CR><LF> (Carriage Return, Line Feed)? I can't think of any other way for the reported symptoms to happen.
I suppose a different regex could be used or another possibility is to open the $var for read and use the IO Layer to deal with different line endings. Of course there is a performance penalty for using this extra layer, but that may not matter.
The below code will read any type of line ending (even if they are mixed).
Anyway the above "nonsensical program" is how I convert a Perl script from a Windows machine for printing on a Unix machine. Perl itself does not care if the Perl source code contains mixed <LF> and <CR><LF> endings, but lpr on Unix does! So this is a simple filter that I use to get rid of any <CR> values before printing some script that might have been edited on my Windows machine and transferred to Unix.#!/usr/bin/perl -w use strict; my $input=<<END; a,b,c,d e,f,g,h i,j,k,l END # a ref to a Perl variable can be opened for reading! # open IN, '<', \$input or die "cannot open var for reading"; while (<IN>) { chomp; print; } #a,b,c,de,f,g,hi,j,k,l __END__ To convert files from Windows that I transfer to Unix: This seemingly nonsensical program converts the line endings... when reading a Windows file on Unix... while(<>) { chomp; # gets rid of <CR><LF> or just<LF> or just <CR> print "$_\n"; # new line ending is just <LF> }
In reply to Re: "chomp" not working
by Marshall
in thread "chomp" not working
by cuautemoc
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |