How do I hide the eol doc chars ^M in VIM - windows

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

Related

make reports "command not found" for an executable on my $PATH

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.

zsh tab completion messes up command line formatting

I'm running zsh with oh-my-zsh on OS X. Every time I use zsh's awesome tab-completion, formatting on the current command line prompt gets really screwed up. For example:
I'll be typing cd fo and try to tab-complete for the 'foo' directory; zsh prompts for completion but changes the command line to cd fo cd fo while it's waiting for me to complete. It's not a big deal but very annoying. Any suggestions?
I had the same issue on PopOS and Arch linux. I tried a bunch of solutions from various places but the only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
The solution is to make a copy of the .zsh-theme file of whatever theme you're using in oh-my-zsh and surround all non-ASCII characters (like emojis) with %{%G<CHARACTER>%}
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
solved the issue for me.
I have faced the same problem before, my solution was disabling some zsh plugins. The second probability is that your colour theme may contain a bug which causing this.
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
This is the final version of my plugin section in the ~/.zshrc file. Any other plugin between parenthesis may be the reason of your situation.
If your problem still continues you need to post your ~/.zshrc to let us check what is in there.
I had the same issue. Interestingly, I saw the problem only iterm2 while the prompt is correctly displayed in the standard terminal of OS X (after reverse-i-search/tab-completion). The reason seems to be that iterm2 defaults to Unicode (UTF-8) default encoding, which however is not correctly interpreted if the corresponding language variable is not set in the shell.
Solution: add the following to your .zshrc
export LC_ALL=en_US.UTF-8
The prompts will be displayed correctly.

Emacs ^m end of line encoding

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.

Cygwin command not found bad characters found in .bashrc 357\273\277

I'm new to Cygwin, I just installed it and attempted to set some simple environment variables. However, when I open the command shell, I get the error "#357\273\277 command not found"
I found an article that discusses what the problem is and how to "discover" the hidden bad character:
http://mblog.lib.umich.edu/DataDiscussions/archives/2010/01/index.html
but I don't know how to resolve the issue by removing the character (which I validated was a problem in my .bashrc file using the od command). I attempted to change the preferences view in Notepad++ to UTF-8 and ANSI to no avail, but the file was not altered at all.
Any help would be appreciated...
As far as I know, a common problem with files saved in Notepad++ as UTF-8 and Cygwin is that Notepad++ saves UTF-8 encoded files with a byte order mark by default. This BOM character is not quite compatible with unix-like environments like Cygwin.
If you need unicode characters in these files, then you can try using the "UTF-8 without BOM" encoding in Notepad++, otherwise you can use ANSI or other encodings that don't use a BOM by default.
Besides the encoding, make sure the file's saved with unix (LF) line-breaks.
Before feeding your files to cygwin bash, you can do a dos2unix conversion first to take care possible conflicts like CR LF. Open bash
name#host ~
$ dos2unix your_file.sh
It looks like if I change the encoding from UTF-8 to ANSI (not the view preferences), the file will update and the special characters are gone, fixing the "\357\273\277 command not found" issue. Hooray!
One way to strip these is in Linux is by using vi. If you say
vi filename
and then in vi use the ed command :se fileencoding=ASCII
this will strip the oddball characters out.
You can confirm this by saving the file and then running od -c on the file.
Before:
od -c changes.sql | head
0000000 357 273 277 I N S E R T I N T O `
After:
od -c changes.sql | head
0000000 I N S E R T I N T O ` c o n
Since you have edited your .bashrc outside of Cygwin and used a Windows editor, the editor might have messed up your newline character (ie. CR, R, etc.) You can tell Notepad++ to show hidden characters. I think you can find it in its settings. Changing charsets is one thing, but being able to see hidden characters is another.
This article mentions a few programs that you can use to convert text files from one standard to another. Try using dos2unix on the file (in the cygwin command line).

Vim: Mac vs. Linux ^M Problem

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

Resources