`^M` in many lines in source code files. How can I remove them?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Someone recently sent me a couple of .cpp source code files. On opening the files with GNU Emacs or GVIM, I found them to have a weird character ^M near the ending of every line.
Here is a screenshot showing what I mean
When I open these same source files with Gedit, I do not see these ^M characters. What should I do? There are many files in question here, so opening and doing a search-replace operation by replaceing with an empty string looks like a back-breaking operation.
Strangely enough these files compile cleanly when I compile with GCC. What is going on here. What should I do?
text-editors cross-platform
edited Oct 9 '16 at 22:51
Burgi
4,435102945
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
add a comment |
Someone recently sent me a couple of .cpp source code files. On opening the files with GNU Emacs or GVIM, I found them to have a weird character ^M near the ending of every line.
Here is a screenshot showing what I mean
When I open these same source files with Gedit, I do not see these ^M characters. What should I do? There are many files in question here, so opening and doing a search-replace operation by replaceing with an empty string looks like a back-breaking operation.
Strangely enough these files compile cleanly when I compile with GCC. What is going on here. What should I do?
text-editors cross-platform
edited Oct 9 '16 at 22:51
Burgi
4,435102945
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
If you will be continually collaborating with this person you should almost certainly do nothing. They do not cause any harm, and if you send any modified files back, then you might cause problems for him, when he tries to use the file.
– Zoredache
Feb 29 '12 at 19:38
add a comment |
Someone recently sent me a couple of .cpp source code files. On opening the files with GNU Emacs or GVIM, I found them to have a weird character ^M near the ending of every line.
Here is a screenshot showing what I mean
When I open these same source files with Gedit, I do not see these ^M characters. What should I do? There are many files in question here, so opening and doing a search-replace operation by replaceing with an empty string looks like a back-breaking operation.
Strangely enough these files compile cleanly when I compile with GCC. What is going on here. What should I do?
text-editors cross-platform
edited Oct 9 '16 at 22:51
Burgi
4,435102945
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
Someone recently sent me a couple of .cpp source code files. On opening the files with GNU Emacs or GVIM, I found them to have a weird character ^M near the ending of every line.
Here is a screenshot showing what I mean
When I open these same source files with Gedit, I do not see these ^M characters. What should I do? There are many files in question here, so opening and doing a search-replace operation by replaceing with an empty string looks like a back-breaking operation.
Strangely enough these files compile cleanly when I compile with GCC. What is going on here. What should I do?
text-editors cross-platform
text-editors cross-platform
edited Oct 9 '16 at 22:51
Burgi
4,435102945
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
edited Oct 9 '16 at 22:51
Burgi
4,435102945
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
edited Oct 9 '16 at 22:51
Burgi
4,435102945
edited Oct 9 '16 at 22:51
Burgi
4,435102945
edited Oct 9 '16 at 22:51
Burgi
4,435102945
4,435102945
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
asked Feb 29 '12 at 19:20
smilingbuddhasmilingbuddha
66231628
66231628
If you will be continually collaborating with this person you should almost certainly do nothing. They do not cause any harm, and if you send any modified files back, then you might cause problems for him, when he tries to use the file.
– Zoredache
Feb 29 '12 at 19:38
add a comment |
If you will be continually collaborating with this person you should almost certainly do nothing. They do not cause any harm, and if you send any modified files back, then you might cause problems for him, when he tries to use the file.
– Zoredache
Feb 29 '12 at 19:38
If you will be continually collaborating with this person you should almost certainly do nothing. They do not cause any harm, and if you send any modified files back, then you might cause problems for him, when he tries to use the file.
– Zoredache
Feb 29 '12 at 19:38
If you will be continually collaborating with this person you should almost certainly do nothing. They do not cause any harm, and if you send any modified files back, then you might cause problems for him, when he tries to use the file.
– Zoredache
Feb 29 '12 at 19:38
add a comment |
5 Answers
5
active
oldest
votes
In Unix, the new line character is n and whereas in Windows it is rn. r or ^M is the carriage-return character.
If the file is written in an editor in windows mode, each new line character will have a carriage return character along. If you tell your editor (and if it understands) to treat the new line characters as in windows, you would not see the ^M characters any more.
Alternately, you can run dos2unix on your codebase to fix this problem.
And as you have rightly observed, you would not see any problems in compiling because that is not any extra special character in the code but just a mismatch between newline character interpretation in windows and linux.
answered Feb 29 '12 at 19:33
MallikMallik
36627
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
add a comment |
You have a source file with mixed Windows and UNIX line endings. While UNIX just used linefeed (sometimes shown as ^J) Windows uses carriage-return + linefeed (sometimes shown as ^M^J). Your editor sees the UNIX lines and says "this must be a UNIX file" but then sees the scattered Windows line endings and says "this is a special character, I must show it".
You can try to convert the file all one way or the other. You can try to use the command dos2unix to convert to UNIX line endings. That will work on the UNIX side, but your Windows side will be confused unless you get a Windows editor that know s UNIX endings.
Or you can use unix2dos and make it all Windows. If you're consistent with the entire file, your UNIX editors (which tend to know Windows endings better than Windows editors know UNIX endings) should be fine. This particular time emacs/gvim was just confused because the file was inconsistent.
As you have seen, the compiler doesn't care what the line ending is.
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
add a comment |
Source insight -> Option -> Preferences -> "Files" tab -> Make "Unix(LF)" in Default file format menu.
answered Mar 9 at 8:03
EunEun
111
add a comment |
According to this resource, ^M is a carriage return - that's why you can compile cleanly with GCC.
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
add a comment |
The reason you see these in emacs/vim is due to how they read things/how things are encoded. The ^M is actually just a Carriage Return (hitting the enter button).
Anyway, you can try doing (in vim, since I don't know the appropriate command in Emacs) :set ff=unix, and then :w, which should turn it into a Unix format and get rid of it the next time you open it (iirc).
Or, if you want explicitly remove ^M from the document, do a search/replace (in Vim, since I only know that) with :%s/<ctrl + v><ctrl + m>//gc.
( This link shows you the commands on how to do a S/R for returns in Emacs. )
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f395439%2fm-in-many-lines-in-source-code-files-how-can-i-remove-them%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
In Unix, the new line character is n and whereas in Windows it is rn. r or ^M is the carriage-return character.
If the file is written in an editor in windows mode, each new line character will have a carriage return character along. If you tell your editor (and if it understands) to treat the new line characters as in windows, you would not see the ^M characters any more.
Alternately, you can run dos2unix on your codebase to fix this problem.
And as you have rightly observed, you would not see any problems in compiling because that is not any extra special character in the code but just a mismatch between newline character interpretation in windows and linux.
answered Feb 29 '12 at 19:33
MallikMallik
36627
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
add a comment |
In Unix, the new line character is n and whereas in Windows it is rn. r or ^M is the carriage-return character.
If the file is written in an editor in windows mode, each new line character will have a carriage return character along. If you tell your editor (and if it understands) to treat the new line characters as in windows, you would not see the ^M characters any more.
Alternately, you can run dos2unix on your codebase to fix this problem.
And as you have rightly observed, you would not see any problems in compiling because that is not any extra special character in the code but just a mismatch between newline character interpretation in windows and linux.
answered Feb 29 '12 at 19:33
MallikMallik
36627
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
add a comment |
In Unix, the new line character is n and whereas in Windows it is rn. r or ^M is the carriage-return character.
If the file is written in an editor in windows mode, each new line character will have a carriage return character along. If you tell your editor (and if it understands) to treat the new line characters as in windows, you would not see the ^M characters any more.
Alternately, you can run dos2unix on your codebase to fix this problem.
And as you have rightly observed, you would not see any problems in compiling because that is not any extra special character in the code but just a mismatch between newline character interpretation in windows and linux.
answered Feb 29 '12 at 19:33
MallikMallik
36627
In Unix, the new line character is n and whereas in Windows it is rn. r or ^M is the carriage-return character.
If the file is written in an editor in windows mode, each new line character will have a carriage return character along. If you tell your editor (and if it understands) to treat the new line characters as in windows, you would not see the ^M characters any more.
Alternately, you can run dos2unix on your codebase to fix this problem.
And as you have rightly observed, you would not see any problems in compiling because that is not any extra special character in the code but just a mismatch between newline character interpretation in windows and linux.
answered Feb 29 '12 at 19:33
MallikMallik
36627
answered Feb 29 '12 at 19:33
MallikMallik
36627
answered Feb 29 '12 at 19:33
MallikMallik
36627
answered Feb 29 '12 at 19:33
MallikMallik
36627
36627
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
add a comment |
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
More ways to do this: sed.sourceforge.net/sed1line.txt under Convert a file from DOS to UNIX and vice versa
– lupincho
Feb 29 '12 at 20:51
add a comment |
You have a source file with mixed Windows and UNIX line endings. While UNIX just used linefeed (sometimes shown as ^J) Windows uses carriage-return + linefeed (sometimes shown as ^M^J). Your editor sees the UNIX lines and says "this must be a UNIX file" but then sees the scattered Windows line endings and says "this is a special character, I must show it".
You can try to convert the file all one way or the other. You can try to use the command dos2unix to convert to UNIX line endings. That will work on the UNIX side, but your Windows side will be confused unless you get a Windows editor that know s UNIX endings.
Or you can use unix2dos and make it all Windows. If you're consistent with the entire file, your UNIX editors (which tend to know Windows endings better than Windows editors know UNIX endings) should be fine. This particular time emacs/gvim was just confused because the file was inconsistent.
As you have seen, the compiler doesn't care what the line ending is.
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
add a comment |
You have a source file with mixed Windows and UNIX line endings. While UNIX just used linefeed (sometimes shown as ^J) Windows uses carriage-return + linefeed (sometimes shown as ^M^J). Your editor sees the UNIX lines and says "this must be a UNIX file" but then sees the scattered Windows line endings and says "this is a special character, I must show it".
You can try to convert the file all one way or the other. You can try to use the command dos2unix to convert to UNIX line endings. That will work on the UNIX side, but your Windows side will be confused unless you get a Windows editor that know s UNIX endings.
Or you can use unix2dos and make it all Windows. If you're consistent with the entire file, your UNIX editors (which tend to know Windows endings better than Windows editors know UNIX endings) should be fine. This particular time emacs/gvim was just confused because the file was inconsistent.
As you have seen, the compiler doesn't care what the line ending is.
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
add a comment |
You have a source file with mixed Windows and UNIX line endings. While UNIX just used linefeed (sometimes shown as ^J) Windows uses carriage-return + linefeed (sometimes shown as ^M^J). Your editor sees the UNIX lines and says "this must be a UNIX file" but then sees the scattered Windows line endings and says "this is a special character, I must show it".
You can try to convert the file all one way or the other. You can try to use the command dos2unix to convert to UNIX line endings. That will work on the UNIX side, but your Windows side will be confused unless you get a Windows editor that know s UNIX endings.
Or you can use unix2dos and make it all Windows. If you're consistent with the entire file, your UNIX editors (which tend to know Windows endings better than Windows editors know UNIX endings) should be fine. This particular time emacs/gvim was just confused because the file was inconsistent.
As you have seen, the compiler doesn't care what the line ending is.
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
You have a source file with mixed Windows and UNIX line endings. While UNIX just used linefeed (sometimes shown as ^J) Windows uses carriage-return + linefeed (sometimes shown as ^M^J). Your editor sees the UNIX lines and says "this must be a UNIX file" but then sees the scattered Windows line endings and says "this is a special character, I must show it".
You can try to convert the file all one way or the other. You can try to use the command dos2unix to convert to UNIX line endings. That will work on the UNIX side, but your Windows side will be confused unless you get a Windows editor that know s UNIX endings.
Or you can use unix2dos and make it all Windows. If you're consistent with the entire file, your UNIX editors (which tend to know Windows endings better than Windows editors know UNIX endings) should be fine. This particular time emacs/gvim was just confused because the file was inconsistent.
As you have seen, the compiler doesn't care what the line ending is.
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
answered Feb 29 '12 at 19:40
Rich HomolkaRich Homolka
25.6k64367
25.6k64367
add a comment |
add a comment |
Source insight -> Option -> Preferences -> "Files" tab -> Make "Unix(LF)" in Default file format menu.
answered Mar 9 at 8:03
EunEun
111
add a comment |
Source insight -> Option -> Preferences -> "Files" tab -> Make "Unix(LF)" in Default file format menu.
answered Mar 9 at 8:03
EunEun
111
add a comment |
Source insight -> Option -> Preferences -> "Files" tab -> Make "Unix(LF)" in Default file format menu.
answered Mar 9 at 8:03
EunEun
111
Source insight -> Option -> Preferences -> "Files" tab -> Make "Unix(LF)" in Default file format menu.
answered Mar 9 at 8:03
EunEun
111
answered Mar 9 at 8:03
EunEun
111
answered Mar 9 at 8:03
EunEun
111
answered Mar 9 at 8:03
EunEun
111
111
add a comment |
add a comment |
According to this resource, ^M is a carriage return - that's why you can compile cleanly with GCC.
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
add a comment |
According to this resource, ^M is a carriage return - that's why you can compile cleanly with GCC.
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
add a comment |
According to this resource, ^M is a carriage return - that's why you can compile cleanly with GCC.
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
According to this resource, ^M is a carriage return - that's why you can compile cleanly with GCC.
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
answered Feb 29 '12 at 19:25
JW8JW8
1,15731226
1,15731226
add a comment |
add a comment |
The reason you see these in emacs/vim is due to how they read things/how things are encoded. The ^M is actually just a Carriage Return (hitting the enter button).
Anyway, you can try doing (in vim, since I don't know the appropriate command in Emacs) :set ff=unix, and then :w, which should turn it into a Unix format and get rid of it the next time you open it (iirc).
Or, if you want explicitly remove ^M from the document, do a search/replace (in Vim, since I only know that) with :%s/<ctrl + v><ctrl + m>//gc.
( This link shows you the commands on how to do a S/R for returns in Emacs. )
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
add a comment |
The reason you see these in emacs/vim is due to how they read things/how things are encoded. The ^M is actually just a Carriage Return (hitting the enter button).
Anyway, you can try doing (in vim, since I don't know the appropriate command in Emacs) :set ff=unix, and then :w, which should turn it into a Unix format and get rid of it the next time you open it (iirc).
Or, if you want explicitly remove ^M from the document, do a search/replace (in Vim, since I only know that) with :%s/<ctrl + v><ctrl + m>//gc.
( This link shows you the commands on how to do a S/R for returns in Emacs. )
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
add a comment |
The reason you see these in emacs/vim is due to how they read things/how things are encoded. The ^M is actually just a Carriage Return (hitting the enter button).
Anyway, you can try doing (in vim, since I don't know the appropriate command in Emacs) :set ff=unix, and then :w, which should turn it into a Unix format and get rid of it the next time you open it (iirc).
Or, if you want explicitly remove ^M from the document, do a search/replace (in Vim, since I only know that) with :%s/<ctrl + v><ctrl + m>//gc.
( This link shows you the commands on how to do a S/R for returns in Emacs. )
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
The reason you see these in emacs/vim is due to how they read things/how things are encoded. The ^M is actually just a Carriage Return (hitting the enter button).
Anyway, you can try doing (in vim, since I don't know the appropriate command in Emacs) :set ff=unix, and then :w, which should turn it into a Unix format and get rid of it the next time you open it (iirc).
Or, if you want explicitly remove ^M from the document, do a search/replace (in Vim, since I only know that) with :%s/<ctrl + v><ctrl + m>//gc.
( This link shows you the commands on how to do a S/R for returns in Emacs. )
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
answered Feb 29 '12 at 19:30
qweetqweet
3,33211515
3,33211515
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f395439%2fm-in-many-lines-in-source-code-files-how-can-i-remove-them%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If you will be continually collaborating with this person you should almost certainly do nothing. They do not cause any harm, and if you send any modified files back, then you might cause problems for him, when he tries to use the file.
– Zoredache
Feb 29 '12 at 19:38