If you transfer text files back and forth between Windows and Unix, you may notice a strange ^M character showing up here and there. There's an easy way to get rid of it, though. Try the first one liner. In a Unix environment, you can remove the \r character (as EOL for Unix is \n) with the second one liner.
On a similar note, the other day I had a postscript file with
an embedded pixmap graphic which contained line breaks represented
only as "\r", in addition to the usual DOS "\r\n" at the
end of each line. The graphic with the \r's came up, in Unix,
as a single over-900K line, which broke most programs I tried
to use to manipulate the file (those programs were not written in
Perl, clearly :-)
So based on this snippet, I came up with the following one-liner:
The use of the forward slash to delimited regular expressions
and replacements has a history of decades - predating the
birth of Perl by years. There are no forward slashes in the
regular expression that could cause confusion. So, other than
a fear of forward slashes, what makes you think use of a
forward slash contributes to obfuscation?
What if you are in a DOS environment and you want to remove what will become the offending ^M when the file is opened in Unix? Running the search and replace doesn't do anything. You still end up with the carriage return instead of the linefeed
Possibly there is a variable that controls this but I haven't found it and things like $OFS in the program and -l012 on the command line don't seem to help (in perl 5.16). Possibly someone might to look into this in more detail.
Along the same lines:
I often get these strange characters ^[[00m when I save the list command into an output file ( ls *.txt > list ) which is visible only in vi. I am aware that these characters appear due to alias ls='ls --color' option in my .bashrc file. I don't want to unalias ls in each window. Is there a similar solution for fixing this?