in reply to Why chomp() is not considering carriage-return
That variable defaults to the EOL (end of line) character for your platform.
So if you run your script on a Unix type OS, only the newline will be removed (since it's expected that on that OS files will end in only a newline).
If you run your script on Windows, the carrage return and newline will both be removed (since it's expected that under Windows files will end in both a carriage return and a newline).
This means that when you chomp a line on a file made on the same OS as where your script is running, the correct thing will happen without your intervention.
If, on the other hand, you want to run a script that will strip the EOL marker off a file regardless of what OS the script is running on and whether that file came from Unix or Windows, you need to do that yourself, with something like:
This works easily due to the neat fact that \r\n and \n both end in \n so the <> operator is going to split Windows and Unix files into lines correctly and all you have to do is strip off the trailing \n and optionally a preceding \r.{ local $/ = "\n"; for my $line (<FILEHANDLE>) { $line =~ s/\r?\n$//; # do your thing } }
Of course the other EOL possibility is that of a Classic MacOS text file, where the EOL marker is a lone carriage return (ie. \r). Mercifully you won't come across these files nearly as much as you used to and dealing with them is an exercise left to the reader ;)
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: chomp() is confusing
by ikegami (Patriarch) on May 23, 2006 at 16:49 UTC | |
by aufflick (Deacon) on May 26, 2006 at 05:33 UTC | |
Re^2: chomp() is confusing
by jesuashok (Curate) on May 15, 2006 at 08:13 UTC | |
by ikegami (Patriarch) on May 23, 2006 at 16:52 UTC | |
by aufflick (Deacon) on May 23, 2006 at 08:01 UTC |