Unix uses 0xA for a newline character. Windows uses a combination of two characters: 0xD 0xA. 0xD is the carriage return character. ^M happens to be the way vim displays 0xD (0x0D = 13, M is the 13th letter in the English alphabet).
You can remove all the ^M characters by running the following:
:%s/^M//g
Where ^M is entered by holding down Ctrl and typing v followed by m, and then releasing Ctrl. This is sometimes abbreviated as ^V^M, but note that you must enter it as described in the previous sentence, rather than typing it out literally.
This expression will replace all occurrences of ^M with the empty string (i.e. nothing). I use this to get rid of ^M in files copied from Windows to Unix (Solaris, Linux, OSX).
I removed them all with sed:
sed -i -e 's/\r//g' <filename>
Could also replace with a different string or character. If there aren't line breaks already for example you can turn \r into \n:
sed -i -e 's/\r/\n/g' <filename>
Those sed commands work on the GNU/Linux version of sed but may need tweaking on BSDs (including macOS).
Let's say your text file is - file.txt, then run this command -
dos2unix file.txt
It converts the text file from dos to unix format.
You can fix this in vim using
:1,$s/^V^M//g
where ^ is the control character.
I've discovered that I've been polluting files for weeks due to the fact that my Homebrew Mvim instance was set to use filetype=dos. Made the required change in .vimrc....
In Unix it is probably easier to use 'tr' command.
cat file1.txt | tr "\r" "\n" > file2.txt
:%s/\r//g
worked for me today. But my situation may have been slightly different.
try :%s/\^M// At least this worked for me.
This is the only thing that worked in my case:
:e ++ff=dos
:wq
It probably means you've got carriage returns (different operating systems use different ways of signaling the end of line).
Use dos2unix to fix the files or set the fileformats in vim:
set ffs=unix,dos
To translate the new line instead of removing it:
:%s/\r/\r/g
If you didn't specify a different fileformat intentionally (say, :e ++ff=unix for a Windows file), it's likely that the target file has mixed EOLs.
For example, if a file has some lines with <CR><NL> endings and others with
<NL> endings, and fileformat is set to unix automatically by Vim when reading it, ^M (<CR>) will appear.
In such cases, fileformats (note: there's an extra s) comes into play. See :help ffs for the details.
If it breaks your configuration, and the ^M characters are required in mappings, you can simply replace the ^M characters by <Enter> or even <C-m> (both typed as simple character sequences, so 7 and 5 characters, respectively).
This is the single recommended, portable way of storing special keycodes in mappings
In FreeBSD, you can clear the ^M manually by typing the following:
:%s/ Ctrl+V, then Ctrl+M, then Ctrl+M again.
I got a text file originally generated on a Windows Machine by way of a Mac user and needed to import it into a Linux MySQL DB using the load data command.
Although VIM displayed the '^M' character, none of the above worked for my particular problem, the data would import but was always corrupted in some way. The solution was pretty easy in the end (after much frustration).
Solution:
Executing dos2unix TWICE on the same file did the trick! Using the file command shows what is happening along the way.
$ file 'file.txt'
file.txt: ASCII text, with CRLF, CR line terminators
$ dos2unix 'file.txt'
dos2unix: converting file file.txt to UNIX format ...
$ file 'file.txt'
file.txt: ASCII text, with CRLF line terminators
$ dos2unix 'file.txt'
dos2unix: converting file file.txt to UNIX format ...
$ file 'file.txt'
file.txt: ASCII text
And the final version of the file imported perfectly into the database.
Source: Stackoverflow.com