What are these ^M's that keep showing up in my files in emacs?

Question

I think it may have to do with TextMate, but we work in a small team and are having some issues with full-file conflicts of nearly identical files in git – in one branch the files have a ^M appended to each line.

What is this mysterious ^M character supposed to do, and where could it be coming from?

Our developers use emacs on Windows/Mac, TextMate on Mac, coda on Mac, and occasionally the wp-admin text editor.

Did anybody ever have this issue stemming from one of those?

Antihelix

For what it's worth: search for "ctrl" instead of ^ – Johns

The bigger issue is, what are you going to do about it? Chances are, Emacs isn't introducing them. Your team should decide whether or not the files should be of DOS format (have ^M) or Unix format (no ^M), and enforce that. – Anette

Does this answer your question? git-diff to ignore ^M – Ats

Answer 1

In git-config, set core.autocrlf to true to make git automatically convert line endings correctly for your platform, e.g. run this command for a global setting:

git config --global core.autocrlf true

Florafloral

I think this is the best answer because it answers the question in the context of the OP, namely git. – Retrospective

I already had "[core]\n autocrlf = true" in my '~/.gitconfig' file, but it still let me 'git clone code.google.com/p/pytomtom' with '^m' chars????? – Whereto

This answer ONLY applies if your platform is Windows! If you work on Mac/Linux, "true" should become "input" ! See help.github.com/articles/dealing-with-line-endings and here: #9226099 – Regelate

WARNING: this answer then corrupts a lot of other files when git incorrectly "guesses" that the line-endings are unimportant and need to be changed. This is lethal for software projects where these characters exist in a data file (yeah, I've been burned by this, painful to un-break). It's a terrible solution IMHO. – Petromilli

@Petromilli What exactly break change of line endings? Where did you have problem, when working with data? It shouldn't affect anything, it's just different way to mark end of row. I just wonder. – Hardee

@Hardee think about it; the comptuer does not "magically" know which CRLF / LF is a line-ending, and which is not. So it changes them all. And if the character was there but NOT as a line-ending ... you just corrupted your data. – Petromilli

Thanks man very much!! I was stuck on this becuase after dual booting my system and switching to linux from windows, I had all my git commit history rendered meaningless because now every file (and I had 1000s of files) had a ^M character and thus every file was listed as modified. I thought I would never get rid of this problem and put in lots of manual hours to correct it or somehow clone it as closely as possible from github. But this one line literally solved my problem in an instant (well only after brainstorming for hours alone on this). Really thanks once again!! – Ronaldronalda

the default of core.autocrlf is false, see here – Triploid

Answer 2

Someone is not converting their line-ending characters correctly.

I assume it's the Windows folk as they love their CRLF. Unix loves LF and Mac loved CR until it was shown the Unix way.

Johns

For clarification: Mac used CR until version 10 (OS X), now it uses LF. – Bonniebonns

I feel that the Windows way is more logical, since the terms CR and LF come from the days of typewriters. You did have to do both: a Carriage Return to get the typing point to the start of the line and a Line Feed to scroll one line down. The Mac OS Classic way (CR) on a typewriter would just keep overwriting the same line. The Unix way (LF) on a typewriter would output staggered text until you reached the full width of the page. :) – Banky

@Otherside: more logical only in the "we want to emulate a typewriter" sense. I can't begin to understand why that is even remotely useful anymore. – Elfrieda

@Banky why would you represent something with two characters when it can be represented with one character? – Canescent

@Matthew G: Everything can be represented in one character, as long as alot of us agree on it. Does that mean we should? We can type all our messages without punctuation, capitals, and just every sentence on a new line, and everyone would understand it. Does that mean we should? It's not about "doing something because we can". That said, I prefer the LF as well. – Kadi

@Banky more logical in 1958. It's not 1958. – Snowber

git config core.autocrlf=input (Linux and no conflict with Windows, tested in a project with linux and windows users over a linux server). Docu – Tacnode

@Otherside, there might be a few more compatibility issues than just the absence or presence of CR, cf. youtube.com/watch?v=2XLZ4Z8LpEE – Slacks

Answer 3

To make the ^M disappear in git, type:

git config --global core.whitespace cr-at-eol

Credits: https://lostechies.com/keithdahlby/2011/04/06/windows-git-tip-hide-carriage-return-in-diff/

Honeysuckle

does not change anything. – Mccary

that only makes the ^M dissappear from the display when use git diff but it is still there – Preraphaelite

Indeed, it only displays the ^M as whitespace, but git diff still takes the ^M into account when comparing files. Remove this setting with git config --global --unset core.whitespace (from this thread). – Cavalry

You can also omit the --global to just configure the current repo. – Diadelphous

This is not right, as git commands don't show but the ^M still in the code base. – Karalynn

Answer 4

^M is 0x0d, i.e. the carriage return character. If your display looks like

line 1^M
line 2^M

then the file must have come from Windows because the standard newline sequence on Windows is CR LF (0x0d 0x0a) whereas the standard newline sequence consists solely of LF on Unices.

If the file had come from a Mac OS 9 or earlier system, you would see it as

line 1^Mline 2^M

because there would be no line feeds following the carriage returns.

Aufmann

This answer explains things clearly. – Soldiery

Answer 5

I'm using Android Studio (JetBrains IntelliJ IDEA) on Mac OS and my problem was that ^M started to show up in some files in my pull request on GitHub. What worked for me was changing line separator for a file.

Open the desired file in the editor go to File go to Line Separators then choose the best option for you (for me it was LF - Unix and OS X(\n) )

According to the next article this problem is a result of confused line endings between operating systems: http://jonathonstaff.com/blog/issues-with-line-endings/

And more information you can find here: https://www.jetbrains.com/help/idea/configuring-line-separators.html#d84378e48

Dogtired

Answer 6

They have to do with the difference between DOS style line endings and Unix style. Check out the Wikipedia article. You may be able to find a dos2unix tool to help, or simply write a small script to fix them yourself.

Edit: I found the following Python sample code here:

string.replace( str, '\r', '' )

Martinic

In Emacs, that would be <code>M-: (replace-string "\r" "")</code>. – Gangrene

Answer 7

instead of query-replace you may also use M-x delete-trailing-whitespace

Alit

this did not work for me...I have selected all text and ran the command. – Jointress

this worked for me. thanks. @devrimbaris, you do not need to select anything, you simply run the command. 'M' is the meta key, or the escape key. So M-x is escape then x. Then you type in delete-trailing-whitespace, and hit return. – Committal

Answer 8

^M at the end of line in Emacs is indicating a carriage return (\r) followed by a line feed (\n). You'll often see this if one person edits files on Windows (where end of line is the combination of carriage return and newline characters) and you edit in Unix or Linux (where end of line is only a newline character).

The combination of characters is usually not harmful. If you're using source control, you may be able to configure the text file checkin format so that lines are magically adjusted for you. Alternatively, you may be able to use checkin and checkout triggers that will automatically "fix" the files for you. Or, you might just use a tool like dos2unix to manually adjust things.

Navarrete

Answer 9

Pot the following in your ~/.emacs (or eqiuvalent)

(defun dos2unix ()
  "Replace DOS eolns CR LF with Unix eolns CR"
  (interactive)
    (goto-char (point-min))
      (while (search-forward "\r" nil t) (replace-match "")))

and then you would be able to simply use M-x dos2unix.

Bainbridge

Answer 10

As everyone has mentioned. It's different line ending style. MacOSX uses Unix line endings - i.e. LF (line feed).

Windows uses both CR (carriage return) & LF (line feed) as a line ending. Since you're using both windows and mac thats where the problem stems from.

If you create a file in windows and then bring it onto the mac you might see these ^M characters at the end of the lines.

If you want to remove them you can do this very easily in emacs. Just highlight and copy the ^M character and do a query-replace ^M with and you'e done.

EDIT: Some other links that may be of help. Link

This one helps you configure emacs to use a particular type of line-ending style. http://www.emacswiki.org/emacs/EndOfLineTips

Ouse

Answer 11

I ran into this issue a while back. The ^M represents a Carriage Return, and searching on Ctrl-Q Ctrl-M (This creates a literal ^M) will allow you get a handle on this character within Emacs. I did something along these lines:

M-x replace-string [ENTER] C-q C-m [ENTER] \n [ENTER]

Celka

Answer 12

If you don't have dos2unix utility installed on your system, you can create your own to get rid of Windows endline characters:

vi ~/dos2unix.bash:

with the following content

#!/bin/bash
tr -d '\r' < $1 > repl.tmp
mv -f repl.tmp $1

In your ~/.bashrc, add the line:

alias 'dos2unix=~/dos2unix.bash'

Applying

dos2unix file_from_PC.txt

will remove ^M characters at lines ends in file_from_PC.txt. You can check if you have those or not by using cat:

cat -v file_from_PC.txt

Manuelmanuela

Answer 13

See also:

Hiding ^M in emacs

Be careful if you choose to remove the ^M characters and resubmit to your team. They may see a file without carriage returns afterward.

Pressmark

Answer 14

One of the most straightforward ways of gettings rid of ^Ms with just an emacs command one-liner:

    C-x h C-u M-| dos2unix    

Analysis:

    C-x h: select current buffer
    C-u: apply following command as a filter, redirecting its output to replace current buffer
    M-| dos2unix: performs `dos2unix` [current buffer]

*nix platforms have the dos2unix utility out-of-the-box, including Mac (with brew). Under Windows, it is widely available too (MSYS2, Cygwin, user-contributed, among others).

Rusk

Answer 15

The solution for me was to use the following elisp function found in this Emacs Wiki Article.

 (defun dos2unix ()
      "Not exactly but it's easier to remember"
      (interactive)
      (set-buffer-file-coding-system 'unix 't) )

Execute the function M-x dos2unix on the buffer and save the file, all ^M will disappear.

Armory