I was wodnering why my emacs started putting ^m at the end of every line, i know how to "fix it" but i was wondering what caused it to happen. I have been using emacs in windows for some time now and it started more recently. Does anyone know why this starts?
Most likely the reason is that the buffer is using '...-unix' coding system when the file contains Windows carriage-return/linefeed line ends. The mode line will show you the coding system in use. See 'Coding Systems' in the Emacs Manual.
Ctrl-h C
will display the coding system currently in use.
I see this happening when the file contains both \r\n and \n\r line endings. That is, someone has written broken Windows line endings to the file (\n\r).
Go through your file and look for lines that start with ^M. This implies that the carriage return was after the newline character on the previous line, which is incorrect.
If that is the case, go back to the program that generated the file and make sure that it's writing correct Windows line endings.
Related
I'm working on a project that requires me to convert a c++ program (prog1.cpp) to a unix text file. I'm using the command
dos2unix prog1.cpp
However, the files that my makefile makes aren't working as they should. make all is supposed to make an executable file hantow which is does, but upon executing hantow the shell reads:
-bash: hantow: command not found
My code is okay, no errors there. I can see there is a file called hantow in the directory and I've already ran
chmod 755 hantow
I wanted to ask if that's the only step you're supposed to take ie.dos2unix or are there any followup commands as well?
well, text-files are pretty universal with one big (or minor) issue: line-endings.
traditionally, text files use different line-endings on differents systems:
CRLF on W32
LF on Un*x
CR on MacOS
Luckily Apple switched to the proper Un*x line-endings when they moved to OSX (a while ago). So these days you will only find two different line-endings.
In the meantime, virtually any decent text-editor will handle text-files of any line-ending convention (I think the big exception is notepad.exe which still can only handle CRLF).
Also any C/C++ compiler will not care at all about the actual line-ending.
So there is no real need to convert a "c++ program to unix text file".
OTOH, I still prefer working with native line-endings whenever possible, and dos2unix is a perfect tool for that. (though modern VCSs will automatically handle line-ending conversion for you, so there is less demand for dos2unix these days).
Finally: your problems with hantow are not related to this.
To answer your specific question: dos2unix should usually be enough to convert the line endings of a file from CRLF to LF. There may be other reasons that the code does not execute, for example if the code uses some other OS-specific functions that are not available in your environment. Also make sure that your Makefile and other input files have the correct line endings. You can call file on the file, to see whether it outputs something like ..., with CRLF line terminators, in which case you might want to run dos2unix on them, too.
I got a new Mac and hammered out some code in Vim. When I viewed the git diff the code I changed had a "^M" after each line. It seems like my new mac is using windows line ending character for some reason. This is not an issue with my text editor because this occurs in both Sublime Text and Vim.
I cannot find any way to edit this in my system preferences and I am not sure where to go from here. It seems like every thread on Stack Overflow addressing this issue either simply offers an explanation of how line endings work or suggest using some third-party service to convert the line endings in a file. I want to know how to change the line endings my Mac inserts.
Vim attempts to use the existing line endings for files. To set the line endings to Unix style explicitly, use
:set fileformat=unix
:w
See :help fileformat for further information. (Note that the Vim help may refer to "mac" style line endings, which refers to Classic Mac OS before 10.x. Mac OS X has always used Unix style line endings.)
I write my Perl code in Textpad (which I believe is only avai in Windows). I run it on Linux cmd prompt by calling the Perl interpreter explicitly, e.g. "perl script.pl". I was wondering if it's possible to run it simply as in "./script.pl". When I add the shebang in Windows, the Linux prompt complains "command not found", but it works fine if I call it with Perl, and also works fine after I dos2unix the script, so the issue seems to be the shebang not being parsed correctly. Any suggestions? Why does the rest of the Windows-formatted code work but not the shebang?
Your problem is that Windows prefers a different line ending convention (CRLF, or \r\n) than other operating systems (LF, or \n). Your editor is creating files with \r\n line endings by default.
The shebang is parsed by the operating system, which is not as forgiving as Perl about the stray \r at the end of the command. It tries to run /usr/bin/perl\r, which doesn't exist.
Your text editor should be able to save the script with Unix line-endings. This won't cause problems with using it on Windows, though a few Windows text editors (including Notepad) won't recognize the line endings properly. This will make it work properly on Linux.
The first line of your file is
#!/usr/bin/perl<CR><LF>
<LF> is the line terminator, so the OS tries to launch /usr/bin/perl<CR>. There is no such program. dos2unix changes the first line to
#!/usr/bin/perl<LF>
<LF> is the line terminator, so the OS tries to launch /usr/bin/perl and succeeds.
I use Vim and GIT to develop my project on a Linux/Ubuntu machine. In the past, I used to use Windows, which means line ends were DOS format. Now after moving to Linux, I always see ^M confusing/annoying characters at the end of the line. Some people here:
How to convert the ^M linebreak to 'normal' linebreak in a file opened in vim?
suggested that I should make a find/replace or use tools like dos2unix. These are good suggestions, but with a version-controlled project it means I have to add unnecessary commits for the files after change, and it is a big task anyway that is not worth spending time on it. So:
Is there anyway to make Vim tolerant for this? That is, if the file is DOS line-ended, it keeps it like this, and use its formatting for new newlines, and so on.
I have added this line to my .vimrc file.
set fileformats=unix,mac,dos
If you don't know what a vimrc file is, it's simply the file that configure (and allows you to customize) your vim. By default vim will be looking for a file called .vimrc (notice the dot at the beginning) in the user's home folder. If it cannot find it, it will source it from /etc/vimrc.
Yes, you can set the following in vim to say it's a dos format file:
:set ff=dos
And, likewise:
:set ff=unix
The best answer I found is #Keith answer in the comments:
"With subversion you can set a property svn:eol-style=native that will cause it to convert line endings to.. native type for all platforms automatically. I don't know if git has that feature, but you might look into that first. It probably does."
And these links might be useful link is how to set:
http://help.github.com/dealing-with-lineendings/
http://git-scm.com/docs/gitattributes
In gvim on windows if I have text with CRLF eol then the text will display ^M at the end of each line.
How do I 'hide' that special char from display?
The :set nolist command """ does not dismiss it.
UPDATE
I did :set fileformats=unix,dos as a list. It didn't work at first, but I closed the file and reopened it again and it worked.
By default I had set fileformats to only unix value.
Thanks for answers.
You may want to set fileformat to dos.
:ed ++ff=dos %
To hide them:
:set fileformats=dos
To remove them (so you can later save the file as a unix file):
:%s/\r//g
While convening on the DOS or Unix format once and for all is of course the preferable approach, sometimes some co-workers just don't care enough about proper source management to make their editors behave.
In those desperate cases, instead of converting the file completely (resulting in a file completely rewritten by yourself according to the SCM, rendering the “blame” function useless), I found it preferable to just pretend that the problem doesn't exist. If the compiler is accommodating, and PHP by all means is, you can have a mixed-EOL file look perfectly cool with the following command:
:match Invisible /\r$/
Or in newer versions of VIM 7.4+
:match Ignore /\r$/
To make things even worse, most GUI editors don't end a text file with a newline, and when a file does end with a newline, they show an empty line at the bottom. Since this is kind of annoying, most people will remove that empty line, which will result in a mixed-EOL file (and the dreadful ^Ms shown in Vim) if the file format was DOS.
If anyone knows how to make Eclipse or NetBeans honor the newline termination without showing the empty last line (as Vim cleverly does), please share your knowledge and you'll make a coder happy here. ;-)
The file format is usually automatically detected. You must have mixed Unix and DOS/Windows lines in your file.
try this to clean it up (where "clean" = unix format):
% tr -d '\015' < old.file > new.file
:0,$ s/<ctrl-v><ctrl-m>//g
:set ff=dos
I'd like to point out that if you are using full blown VIM (at least on my ubuntu 9.10 box) it "does what you want" and auto-hides it, but the stock vi (and vim-tiny) do NOT auto-hide the ^M. If you do a minimal install (or server install) you get vi and vim-tiny only. The fix I found was to install proper vim (apt-get install vim) on my ubuntu box. Hope that helps someone that comes along this topic for the same reason I did :-D
use the command:
:1,$ s/^v^M/ /g
When my neovim showed me these ugly ^M in some files from node_modules, I fixed this by adding following code to BufWinEnter:
if char2nr(getline(1)[-1:-1]) == 13
e ++ff=dos
endif