237

Is there a text editor on Linux that allows me to see line breaks and carriage returns? Does Vim support this feature?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
usertest
  • 27,132
  • 30
  • 72
  • 94
  • 1
    NOTE: sometimes newline ($) and carriage return (^M) are hidden in MANY color schemes, and also while using putty to ssh. – Vanessa Sanchez Aug 21 '17 at 18:06
  • 1
    OP I think you should reconsider the selected answer. as the selected answer doesn't work. but CaptSaltyJack answer works well. – JavaSheriff Dec 13 '18 at 16:36
  • OP 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 – Wayne Walker Dec 18 '19 at 20:02
  • You can also display the `fileformat` in the status bar. I have `[dos]` or `[unix]` display in my status bar. – NeilG May 31 '23 at 08:00

9 Answers9

333

To disagree with the official answer: :set list alone will not show ^M characters (CRs).

Solutions that do work:

  • vim -b (add the -b option when starting vim) -or-
  • :e ++ff=unix (while vim is running)
Rob Bednark
  • 25,981
  • 23
  • 80
  • 125
CaptSaltyJack
  • 15,283
  • 17
  • 70
  • 99
  • 5
    It's the Syntax. `:help edit` shows `e[dit]! [++opt] [+cmd]`. And `:help ++e` says _The [++opt] argument can be used to force the value of 'fileformat' [..]_. – dennis Oct 06 '15 at 11:35
  • 26
    just to clarify, `:set list` shows newline (`$`), `:e ++ff=unix` shows CR (`^M`); if you want to see both, `:set list` then `:e ++ff=unix` – Yibo Yang Aug 21 '16 at 22:16
  • 8
    To 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 as `unix` without actually changing the contents. So vim reads it like a Unix file, sees the CR characters as extra and displays them as ^M. – Sundar R Apr 20 '18 at 22:41
  • 1
    Does this command change under Mac? I'm still not able to see CRs – Dici Oct 13 '18 at 11:42
  • 3
    Neither still doesn't work for me in `vim` for some reason... I mean neither `-b` option, nor `:e ++ff=unix` when inside :( – RAM237 Oct 30 '18 at 10:41
  • 3
    all right, :e ++ff=unix worked. Now how do I turn it off? – Croo Apr 12 '19 at 09:06
  • Can be turned off (or back) to either Windows with `:e ++ff=dos` or Mac `:e ++ff=mac` – Stuart Brock Aug 14 '19 at 10:15
  • `:e ++ff=unix` or `-b` shows nothing special in my source `.cpp` files. What's wrong? – z0lupka Jun 01 '21 at 11:33
  • Not 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`. – midnite Dec 29 '21 at 05:54
  • how do I put this into my .vimrc file – Gerry Sep 15 '22 at 21:48
155

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'.

Shyam Habarakada
  • 15,367
  • 3
  • 36
  • 47
jay.lee
  • 19,388
  • 8
  • 39
  • 38
  • 2
    Same question here: http://superuser.com/questions/97692/vim-show-line-feeds-carriage-return – Alec Jacobson Oct 05 '10 at 02:52
  • 299
    Incorrect, `: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` – CaptSaltyJack Apr 21 '13 at 16:22
  • 21
    FYI, to turn off the "set list" mode, use `:set nolist` – Tomofumi Oct 23 '17 at 02:09
  • @Tomofumi an edit with your perposition will be welcome! – Pipo Jan 30 '18 at 22:35
  • 4
    WRONG answer. :set list will NOT show ^M characters (CRs). Use -b option to vi/vim will work. – nanosoft Mar 13 '18 at 13:10
  • 1
    As I understand it, Vim will show the ^M characters only if it thinks the `fileformat` of the file is `unix`. 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 Apr 20 '18 at 22:37
  • While 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 – Kiteloopdesign Mar 18 '20 at 18:28
  • Updated 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=...` – Shyam Habarakada Aug 28 '21 at 04:37
80

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Larry K
  • 47,808
  • 15
  • 87
  • 140
  • I 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. Will `vi -b filename` or `:set binary` just show `^M` if it is a windows type file and no other line endings otherwise? – alpha_989 May 25 '18 at 20:45
41

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.

pjvleeuwen
  • 4,215
  • 1
  • 18
  • 31
Paweł Smolak
  • 593
  • 6
  • 12
12

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Brian S. Wilson
  • 561
  • 4
  • 11
  • Unfortunately in my system (Ubuntu 16.04) `set binary` is not the same as `vim -b filename.py`. Any idea why? I did check the `help` and it does seem that what you say is generally correct. How do I figure out why this is so? – alpha_989 May 25 '18 at 20:52
  • `:e ++ff=unix` does show the `^M` correctly and doesn't show it when I use `unix` type files.. So I guess the problem is solved for now... – alpha_989 May 25 '18 at 20:54
7

I suggest you to edit your .vimrc file, for running a list of commands.

Edit your .vimrc file, like this:

cat >> ~/.vimrc <<EOF
set ffs=unix
set encoding=utf-8
set fileencoding=utf-8
set listchars=eol:¶
set list
EOF

When you're executing Vim, the commands in file .vimrc are executed, and you can see this example:

My line with CRLF eol here ^M¶
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Arno
  • 1,309
  • 14
  • 20
7

By using cat and -A you can see new lines as $ and tabs as ^I:

cat -A myfile
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
mirhossein
  • 682
  • 7
  • 16
  • 2
    '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.). – Juan Jul 24 '20 at 22:51
  • 1
    And `:%!cat -A` to use in vim (although that changes the contents of the buffer of course) – Hielke Walinga Oct 27 '20 at 19:05
  • [See answer here](https://unix.stackexchange.com/a/389616/216300) for more details: When you do `cat -A myfile`, then `hello^M$` means crlf endings, `hello$` for lf endings. – RyanQuey Apr 06 '23 at 03:26
0

You can view break lines using the gedit editor.

First, if you don't have it installed, for Debian/Ubuntu/Mint based distros:

sudo apt-get install gedit

For Fedora/CentOS/RedHat based distros:

sudo dnf install gedit

or

sudo yum install gedit

Now, install gedit plugins:

sudo apt-get install gedit-plugins

or

Under Gnome2, user plugins were put into ~/.gnome2/gedit/plugins/
For Gnome3: ~/.local/share/gedit/plugins/

Download the plugins from: https://help.gnome.org/users/gedit/stable/gedit-plugin-guide.html.en#gedit-additional-plugins

and select Draw Spaces plugin, enter on Preferences, and chose Draw new lines:

Enter image description here

Enter image description here

Using Visual Studio Code, you can install the Line endings extension.

Sublime Text 3 has a plugin called RawLineEdit that will display line endings and allow the insertion of arbitrary line-ending type

Shift + Ctrl + P and start type the name of the plugin, and toggle to show line endings.

danilo
  • 7,680
  • 7
  • 43
  • 46
  • `apt-get` will not work on all Linux systems (this question's scope). Perhaps state the assumptions? [Ubuntu](https://en.wikipedia.org/wiki/Ubuntu_%28operating_system%29)? [Linux Mint](https://en.wikipedia.org/wiki/Linux_Mint)? [Ubuntu MATE](https://en.wikipedia.org/wiki/Ubuntu_MATE)? [Debian](https://en.wikipedia.org/wiki/Debian)? – Peter Mortensen Apr 08 '21 at 11:11
  • @PeterMortensen, I added steps for CentOS,RedHad,Fedora (for Gnome desktop environments) – danilo Jan 27 '22 at 19:18
-1

Add the following alias to your .bashrc or .bash_aliases:

alias vidos='vi  -c ":e ++ff=unix" -c "set list"'

Then you can use vidos to edit the file and see newline as $ and carriage return as ^M.

Tyler2P
  • 2,324
  • 26
  • 22
  • 31
user19800241
  • 1