See line breaks and carriage returns in editor
Solution 1
Assuming your vim settings for :set listchars=...
is set to visualize the characters you are attempting to see, in this case the carriage return characters (typed with CTL + V, CTRM + M) —— otherwise, as reported in many of the comments on this answer, the ^M character will not show on :set list
:set list
in Vim will show whitespace. End of lines show as '$
' and carriage returns usually show as '^M
'.
Solution 2
To disagree with the official answer:
:set list
will not show ^M characters (CRs). Supplying the -b option to vi/Vim will work. Or, once Vim is loaded, type :e ++ff=unix
.
Solution 3
vi shows newlines (LF character, code x0A
) by showing the subsequent text on the next line.
Use the -b
switch for binary mode. For example , vi -b filename
or vim -b filename --
.
It will then show CR characters (x0D
), which are not normally used in Unix style files, as the characters ^M
.
Solution 4
Just to clarify why :set list
won't show CR's as ^M
without e ++ff=unix
and why :set list
has nothing to do with ^M
's.
Internally when Vim reads a file into its buffer, it replaces all line-ending characters with its own representation (let's call it $
's). To determine what characters should be removed, it firstly detects in what format line endings are stored in a file. If there are only CRLF '\r\n'
or only CR '\r'
or only LF '\n'
line-ending characters, then the 'fileformat'
is set to dos
, mac
and unix
respectively.
When list
option is set, Vim displays $
character when the line break occurred no matter what fileformat
option has been detected. It uses its own internal representation of line-breaks and that's what it displays.
Now when you write buffer to the disc, Vim inserts line-ending characters according to what fileformat
options has been detected, essentially converting all those internal $
's with appropriate characters. If the fileformat
happened to be unix
then it will simply write \n
in place of its internal line-break.
The trick is to force Vim to read a dos
encoded file as unix
one. The net effect is that it will remove all \n
's leaving \r
's untouched and display them as ^M
's in your buffer. Setting :set list
will additionally show internal line-endings as $
. After all, you see ^M$
in place of dos
encoded line-breaks.
Also notice that :set list
has nothing to do with showing ^M
's. You can check it by yourself (make sure you have disabled list
option first) by inserting single CR using CTRL-V
followed by Enter
in insert mode. After writing buffer to disc and opening it again you will see ^M
despite list
option being set to 0.
You can find more about file formats on http://vim.wikia.com/wiki/File_format or by typing:help 'fileformat'
in Vim.
Solution 5
Try the following command.
:set binary
In Vim, this should do the same thing as using the "-b" command line option. If you put this in your startup (i.e., .vimrc) file, it will always be in place for you.
On many *nix systems, there is a "dos2unix" or "unix2dos" command that can process the file and correct any suspected line ending issues. If there aren't any problems with the line endings, the files will not be changed.
Related videos on Youtube
usertest
Updated on January 28, 2022Comments
-
usertest over 2 years
Is there a text editor on Linux that allows me to see line breaks and carriage returns? Does Vim support this feature?
-
Vanessa Sanchez over 6 yearsNOTE: sometimes newline ($) and carriage return (^M) are hidden in MANY color schemes, and also while using putty to ssh.
-
JavaSheriff over 5 yearsOP I think you should reconsider the selected answer. as the selected answer doesn't work. but CaptSaltyJack answer works well.
-
Wayne Walker over 4 yearsOP What will show BOTH is @arno 's solution. I needed to see BOTH, because I have a file randomly using all 3 fileformats... And arno 's solution works
-
-
Alec Jacobson over 13 yearsSame question here: superuser.com/questions/97692/…
-
CaptSaltyJack about 11 yearsIncorrect,
:set list
will NOT show^M
characters (CRs). Supplying the-b
option to vi/vim will work. Or, once vim is loaded, type::e ++ff=unix
-
dennis over 8 yearsIt's the Syntax.
:help edit
showse[dit]! [++opt] [+cmd]
. And:help ++e
says The [++opt] argument can be used to force the value of 'fileformat' [..]. -
Yibo Yang over 7 yearsjust to clarify,
:set list
shows newline ($
),:e ++ff=unix
shows CR (^M
); if you want to see both,:set list
then:e ++ff=unix
-
Tomofumi over 6 yearsFYI, to turn off the "set list" mode, use
:set nolist
-
Pipo over 6 years@Tomofumi an edit with your perposition will be welcome!
-
nanosoft about 6 yearsWRONG answer. :set list will NOT show ^M characters (CRs). Use -b option to vi/vim will work.
-
Sundar R about 6 yearsAs I understand it, Vim will show the ^M characters only if it thinks the
fileformat
of the file isunix
. This usually happens when one or more lines ends with the\n
unix-style line break character, but the others end with\r\n
CRLF combination that Windows uses. Then the lines with the CRLF line ending will show the ^M character. -
Sundar R about 6 yearsTo expand on @dennis's comment,
:set ff=unix
tells Vim to change the line endings to unix style (as part of setting the fileformat), so the ^M characters are no longer there (and so are not displayed).:e ++ff=unix
tells it to force-set the fileformat asunix
without actually changing the contents. So vim reads it like a Unix file, sees the CR characters as extra and displays them as ^M. -
alpha_989 almost 6 yearsI typically dont need to see the line ending, because I mostly work in
Unix
environment. But I would like to be warned about Windows type line endings if there is any in the file. Willvi -b filename
or:set binary
just show^M
if it is a windows type file and no other line endings otherwise? -
alpha_989 almost 6 yearsUnfortunately in my system (Ubuntu 16.04)
set binary
is not the same asvim -b filename.py
. Any idea why? I did check thehelp
and it does seem that what you say is generally correct. How do I figure out why this is so? -
alpha_989 almost 6 years
:e ++ff=unix
does show the^M
correctly and doesn't show it when I useunix
type files.. So I guess the problem is solved for now... -
Dici over 5 yearsDoes this command change under Mac? I'm still not able to see CRs
-
RAM237 over 5 yearsNeither still doesn't work for me in
vim
for some reason... I mean neither-b
option, nor:e ++ff=unix
when inside :( -
Croo about 5 yearsall right, :e ++ff=unix worked. Now how do I turn it off?
-
Stuart Brock over 4 yearsCan be turned off (or back) to either Windows with
:e ++ff=dos
or Mac:e ++ff=mac
-
Kiteloopdesign about 4 yearsWhile what @Tomofumi says is perfectly correct, I prefer to do
:set list!
to switch between modes. Just faster to type, plus you can use vim's history to find the command faster, and just add (or remove) the '!' from the end of the command -
Juan almost 4 years'cat -A' is not as portable as 'cat -e'. -A is supported by GNU coreutils version of cat(1), but not other implementations (e.g., bsd, macos, etc.).
-
Hielke Walinga over 3 yearsAnd
:%!cat -A
to use in vim (although that changes the contents of the buffer of course) -
Peter Mortensen about 3 years
apt-get
will not work on all Linux systems (this question's scope). Perhaps state the assumptions? Ubuntu? Linux Mint? Ubuntu MATE? Debian? -
z0lupka almost 3 years
:e ++ff=unix
or-b
shows nothing special in my source.cpp
files. What's wrong? -
Shyam Habarakada over 2 yearsUpdated answer to clarify why
:set list
would not work as expected for many of you. It has to do with the configuration of:set listchars=...
-
midnite over 2 yearsNot sure why these methods do not work for me. I have just found a convenient way to indicate the
\n
or\r
or\r\n
. Just search them and they will be highlighted. Type/\n
or/\r
or/\r\n
. -
danilo over 2 years@PeterMortensen, I added steps for CentOS,RedHad,Fedora (for Gnome desktop environments)