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.
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
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?
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?