Re^2: Make my script faster and more efficient

# I don't use chomp, sorry

Why not?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^2: Make my script faster and more efficient
Re^3: Make my script faster and more efficient by quester (Vicar) on Dec 03, 2008 at 06:07 UTC
I've gotten gun-shy of chomp as well. In a mixed Unix/Windows environment, or running Cygwin, it's pretty common for $/ to not be set by default to the same line ending that is used in (some of) the input file(s). Monarch's method is more tolerant of incorrect or inconsistent line endings than chomp.	[reply]
Re^4: Make my script faster and more efficient by oshalla (Deacon) on Dec 03, 2008 at 13:28 UTC
Indeed so: `CR`s can sneak in and ruin your day. Looking at: `$_ =~ s/[\r\n]+\z//s ;` makes me twitch a bit, since the values of `"\r"` and `"\n"` can vary. However, the best known case of `"\n" ne "\x0A"` is (old) Mac systems where `"\n" eq "\x0D"` and `"\r" eq "\x0A"` , so `[\r\n]` appears safe. [Nevertheless, I haven't found anything that guarantees that `"\n"` and `"\r"` are duals. perlport touches on systems where they aren't ASCII at all, but that's a whole other world of pain.] Anyway, I favour: `$_ =~ s/\s+\z// ;` on the basis that it finesses the issue and gets rid of any other trailing whitespace -- two birds, one stone. Mind you, I have seen `"\s"` defined to be `[ \t\n\r\f]` -- but current perlreref says it's "whitespace".	[reply] [d/l] [select]