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).
Related
This question already has answers here:
running bash script in cygwin on windows 7 [duplicate]
(2 answers)
Are shell scripts sensitive to encoding and line endings?
(14 answers)
Closed 3 years ago.
I have windows, using Cygwin, trying to set JAVA_HOME permanently through my .bashrc file.
.bashrc:
export PATH="$JAVA_HOME/bin:$PATH"
export JAVA_HOME=$JAVA_HOME:"/cygdrive/c/Program Files (x86)/Java/jdk1.7.0_05"
.bash_profile:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
running cygwin:
-bash: $'\377\376if': command not found
-bash: $'then\r': command not found
: No such file or directorysu//.bashrc
-bash: /cygdrive/c/Users/jhsu//.bash_profile: line 3: syntax error near unexpected token `fi'
-bash: /cygdrive/c/Users/jhsu//.bash_profile: line 3: `fi'
I am not sure if I took the commands from a tutorial that was meant for another system or if I am missing a step. Or whitespace is causing my commands not to run properly.
I've looked at multiple similar questions but I haven't found one where the question has my error exactly.
My home path:
$ echo $HOME
/cygdrive/c/Users/jhsu
$ echo ~
/cygdrive/c/Users/jhsu/
So I believe the files should be placed in the correct spot.
When all else fails in Cygwin...
Try running the dos2unix command on the file in question.
It might help when you see error messages like this:
-bash: '\r': command not found
Windows style newline characters can cause issues in Cygwin.
The dos2unix command modifies newline characters so they are Unix / Cygwin compatible.
CAUTION: the dos2unix command modifies files in place, so take precaution if necessary.
If you need to keep the original file, you should back it up first.
Note for Mac users: The dos2unix command does not exist on Mac OS X.
Check out this answer for a variety of solutions using different tools.
There is also a unix2dos command that does the reverse:
It modifies Unix newline characters so they're compatible with Windows tools.
If you open a file with Notepad and all the lines run together, try unix2dos filename.
For those who don't have dos2unix installed (and don't want to install it):
Remove trailing \r character that causes this error:
sed -i 's/\r$//' filename
Explanation:
Option -i is for in-place editing, we delete the trailing \r directly in the input file. Thus be careful to type the pattern correctly.
For WINDOWS (shell) users with Notepad++ (checked with v6.8.3) you can correct the specific file using the option
Edit
-> EOL conversion
-> Unix/OSX format
And save your file again.
Edit: still works in v7.5.1 (Aug 29 2017)
Edit: Jan 3, 2022. As VSCode is mentioned several times. Go to settings in VSCode and type files.eol in the search field and set to \n (Unix format). Note that this changes this setting for your user or workspace for all files and it may not be what you want. YMMV.
I am using cygwin and Windows7, the trick was NOT to put the set -o igncr into your .bashrc but put the whole SHELLOPTS into you environment variables under Windows. (So nothing with unix / cygwin...) I think it does not work from .bashrc because "the drops is already sucked"
as we would say in german. ;-)
So my SHELLOPTS looks like this
braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor
SUBLIME TEXT
With sublime you just go to
View - > Line Endings -> (select)Unix
Then save the file. Will fix this issue.
Easy as that!
If you are using a recent Cygwin (e.g. 1.7), you can also start both your .bashrc and .bash_profile with the following line, on the first non commented line:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
(set -o igncr) 2>/dev/null && set -o igncr; # this comment is needed
This will force bash to ignore carriage return (\r) characters used in Windows line separators.
See http://cygwin.com/ml/cygwin-announce/2010-08/msg00015.html.
The error:
'\r': command not found
is caused by shell not able to recognise Windows-like CRLF line endings (0d 0a) as it expects only LF (0a).
Git
If you using Git on Windows, make sure you selected 'Checkout as-is' during setup. Then make sure that you run: git config --global core.autocrlf false, so Git will not perform any conversions when checking out or committing text files.
dos2unix
If you're not using Git, you simply need to convert these affected files/scripts back into Unix-like line endings (LF), either by:
dos2unix ~/.bashrc
Note: The dos2unix command is part of dos2unix package.
Ex/Vim editor + tr
If you've Vim installed, the following command should correct the files:
ex +'bufdo! %! tr -d \\r' -scxa ~/.bash*
Useful alias: alias dos2unix="ex +'bufdo! %! tr -d \\\\r' -scxa".
tr
Here is the method by using tr:
cat ~/.bashrc | tr -d '\r' > ~/.bashrc.fixed && mv -v ~/.bashrc.fixed ~/.bashrc
or:
tr -d '\r' < filename > new_filename
Note: The \r is equivalent to \015.
sed
You can try the following command:
sed -i'.bak' s/\r//g ~/.bash*
recode
The following aliases can be useful (which replaces dos2unix command):
alias unix2dos='recode lat1:ibmpc'
alias dos2unix='recode ibmpc:lat1'
Source: Free Unix Tools (ssh, bash, etc) under Windows.
perl
The following perl command can convert the file from DOS into Unix format:
perl -p -i.bak -e 's/\015//g' ~/.bash*
Source: stripping the ^M.
tofrodos
On Linux, like Ubuntu which doesn’t come standard with either dos2unix or unix2dos, you can install tofrodos package (sudo apt-get install tofrodos), and define the following aliases:
alias dos2unix=’fromdos’
alias unix2dos=’todos’
Then use in the same syntax as above.
Vagrant
If you're using Vagrant VM and this happens for provisioning script, try setting binary option to true:
# Shell provisioner, see: https://www.vagrantup.com/docs/provisioning/shell.html
config.vm.provision "shell" do |s|
s.binary = true # Replace Windows line endings with Unix line endings.
s.path = "script.sh"
end
See: Windows CRLF to Unix LF Issues in Vagrant.
try execution the following command
vim .bashrc
:set ff=unix
:wq!
You can also add the option -o igncr to the bash call, e.g.
bash -x -o igncr script.sh
As per this gist, the solution is to create a ~/.bash_profile (in HOME directory) that contains:
export SHELLOPTS
set -o igncr
May be you used notepad++ for creating/updating this file.
EOL(Edit->EOL Conversion) Conversion by default is Windows.
Change EOL Conversion in Notepad++
Edit -> EOL Conversion -> Unix (LF)
I had the same problem. Solution: I edit the file with pspad editor, and give it a unix format (Menu - Format -> UNIX)
I believe you can set this format to your file with many other editors
For the Emacs users out there:
Open the file
M-x set-buffer-file-coding-system
Select "unix"
This will update the new characters in the file to be unix style. More info on "Newline Representation" in Emacs can be found here:
http://ergoemacs.org/emacs/emacs_line_ending_char.html
Note: The above steps could be made into an Emacs script if one preferred to execute this from the command line.
Issue maybe occured because of the file/script created/downloaded from a windows machine. Please try converting into linux file format.
dos2unix ./script_name.sh
or
dos2unix ~/.bashrc
If you have the vim package installed on your Cygwin install, you can use vim to fix this without find & replace. Start vim as follows: vim filename.sh (often it is aliased to vi also). Then, type :set fileformat=unix, then :wq (write & quit) to save your changes. (The : puts you in vim's edit mode.)
I recommend this over dos2unix since vim is probably more commonly installed.
However, it is probably a best practice to set your text editor to save files that you plan to use in a Unix/Linux environment to have a Unix text format. The answers given above for Notepad++ are a good example.
Additional note: If you are unsure what type a file is (DOS or Unix), you may use the file filename.sh. This can especially help in debugging more obscure issues (such as encoding issues when importing SQL dumps that come from Windows).
For other options on how to modify text file formatting, see this IU knowledge base article
More background information on Bash scripts and line endings is found on this StackOverflow question.
In EditPlus you do this from the
Document → File Format (CR/LF) → Change File Format... menu and then choose the Unix / Mac OS X radio button.
1. Choice
EditorConfig — is my choice.
2. Relevance
This answer is relevant for March 2018. In the future, the data from this answer may be obsolete.
Author of this answer personally used EditorConfig at March 2018.
3. Limitations
You need to use one of supported IDE/editors.
4. Argumentation
Simply usage. I need set my .editorconfig file 1 time, where I create my project, → I can forget some platform-, style- and IDE-specific problems.
Cross-platform, cross-languages, cross-IDE, cross-editors.
5. Example
5.1. Simple
I install EditorConfig plugin for Sublime Text → my text editor. I edit files in Sublime Text.
For example, I have sashacrlf.sh file:
echo "Sasha" &
echo "Goddess!" &
I run this file in Cygwin:
$ bash sashacrlf.sh
Sasha
sashacrlf.sh: line 1: $'\r': command not found
Goddess!
I create a file .editorconfig in same project as sashacrlf.sh.
[*.sh]
end_of_line = lf
It means, that if you save any file with .sh extension in your project in your editor, EditorConfig set UNIX line endings for this file.
I save sashacrlf.sh in my text editor again. I run sashacrlf.sh again:
$ bash sashacrlf.sh
Sasha
Goddess!
I can't get unexpected output in console.
5.2. Multiple file extensions
For example, I want to have UNIX line endings in all files with extensions .sh, .bashrc and .bash_profile.
I add these lines to my .editorconfig file:
[*.{sh,bashrc,bash_profile}]
end_of_line = lf
Now, if I save any file with .sh, .bashrc or .bash_profile extension, EditorConfig automatically set UNIX line ending for this file.
6. Additional links
EditorConfig official site.
File is bidd.nus.edu.sg/group/TTD/filedownload.asp?file=flatfiles/drug-disease_TTD2013.txt
When I use cat -A drug-disease_TTD2013.txt it shows ^M$ in the end of each line. In vim, set list and it shows only $ without ^M.
sed 's/\r//' drug-disease_TTD2013.txt >1.t can make it the same. but I do not know why? (revised)
Also in manual of cat: -v use ^ and M- notation, except for LFD and TAB What's the meaning of that?
not the same situation in this other question
Thank you.
In vim, type
:set ff?
I suppose it will respond with
fileformat=dos
That means that the end of line is ␍␊ (^M^J, \r\n) rather than just ␊ (^J, \n). This is autodetected by vim when opening the file if all newlines are consistently the same two-byte sequence.
To re-open the file in unix mode, just type:
:e ++ff=unix
now it will show the ^M characters. It will show them even without list option, because they now are in the buffer as regular characters.
cat is a Unix tool, and as such expects the platform's line endings, LF (^J).
Vim is multi-platform and detects the (consistent) use of different line endings. Your file apparently has Windows-style CR-LF line endings, so Vim just shows the $ sigil.
To change that, you can explicitly specify the fileformat on opening:
$ vim -c 'set list' -c 'edit ++fileformat=unix drug-disease_TTD2013.txt'
If you're just on Linux / Unix systems, it's probably easiest to convert the source file to Unix-style line endings, using either sed, dos2unix, or Vim.
I'm having some trouble getting unicode to work for git-bash (on windows 7). I have tried many things without success. Although, I'm not quite sure what is responsible to for this so i might be working in the wrong direction.
It really seems this should be possible as the encoding for cmd.exe can be changed to unicode with 'chcp 65001'.
Here are some things I've tried (besides the obvious of looking through the configuration options in the GUI).
Setting environment variables in '.bashrc'. I guess it makes sense this doesn't work since i think it's a linux thing. The 'locale' command does not exist.
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
Starting out in cmd.exe, changing the encoding to unicode with 'chcp 65001' and then starting up git-bash. This causes me to get a permission denied when trying to cat my unicode test file. However, catting a file without unicode works just fine. As demonstrated, dropping back out to cmd.exe i can still "cat" the file. Using my default encoding (437) i can cat the file in bash (no permission denied but the output is fudged).
S:\>chcp 65001
Active code page: 65001
S:\>"C:\Program Files (x86)\Git\bin\sh.exe" --login -i
zarac#TOWELIE /z
cat /s/unicode.txt
cat: write error: Permission denied
zarac#TOWELIE /z
cat /s/nounicode.txt
abc
zarac#TOWELIE /z
L /s/unicode.txt
-rw-r--r-- 1 zarac Administ 7 May 18 10:30 /s/unicode.txt
zarac#TOWELIE /z
whoami
towelie\zarac
zarac#TOWELIE /z
exit
Z:\>type S:\unicode.txt
abc£
Using the /U flag when starting the shell (makes sense that it doesn't work because it's not quite what it's for if-i-understand-correctly, but it has to do with unicode so i tried it).
C:\Windows\SysWOW64\cmd.exe /U /C "C:\Program Files (x86)\Git\bin\sh.exe" --login -i
As I prefer to use Console2, I've tried adding a dword value named CodePage with the value 65001 (decimal) to the windows registry under [HKEY_CURRENT_USER\Console] as well as [HKEY_CURRENT_USER\Console\Git Bash]. This seems to have the same effect as setting 'chcp 65001' accept that it's "automatic". (http://stackoverflow.com/questions/379240/is-there-a-windows-command-shell-that-will-display-unicode-characters)
JPSoft's TCC/LE
PowerCMD
stackoverflow
duckduckgo
ixquick / google
So, method 2 seems viable if that permission issue can be fixed. However, I'm open to pretty much any solution although i prefer if i can use Console2 (due mostly to it's nifty tab feature). Perhaps one solution would be to setup an SSH server and then use Putty/Kitty to connect to it, but that's just wrong! ; )
PS. Is there any official documentation for git-bash?
I faced the same issue in MSYS Git 2.8.0 and as it turned out it just needed changing the configuration.
$ git --version
git version 2.8.0.windows.1
The default configuration of Git Bash console in my system did not show Greek filenames.
$cd ~
$ls
AppData/
'Application Data'#
Contacts/
Cookies#
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'#
NTUSER.DAT
.
.
.
''$'\316\244\316\261'' '$'\316\255\316\263\316\263\317\201\316\261\317\206\316\254'' '$'\316\274\316\277\317\205'#
The last line should display "Τα έγγραφά μου", the greek translation of "My Documents". In order to fix it I followed the below steps:
Check your existing locale configuration
$locale
LANG=en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
As shown above, in my case it was not UTF-8
Change the locale to a UTF-8 encoding. Click the icon on the left side of MINGW title bar, select "Options" and in the "Text" category choose "UTF-8" Character set. You should also choose a unicode font, such as the default "Lucida Console". My configuration looks as following:
Change the language for the current window (no need to do this on future windows, as they will be created with the settings of step 2)
$ LANG='C.UTF-8'
The ls command should now display properly
AppData/
'Application Data'#
Contacts/
Cookies#
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'#
NTUSER.DAT
.
.
.
'Τα έγγραφά μου'#
Found this answer elsewhere:
chcp.com 65001
Git bash chcp windows7 encoding issue
That's what actually solved it for me.
As CharlesB said in a comment, msysgit 1.7.10 handles unicode correctly. There are still a few issues but I can confirm that updating did solve the issue I was having.
See: https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support
Check if the issue persists with Git 2.1 (August 2014).
See commit 617ce96 or commit 1c950a5 by Karsten Blees (kblees)
Win32: support Unicode console output
WriteConsoleW seems to be the only way to reliably print unicode to the
console (without weird code page conversions).
Also redirects vfprintf to the winansi.c version.
Win32: add Unicode conversion functions
Add Unicode conversion functions to convert between Windows native UTF-16LE encoding to UTF-8 and back.
To support repositories with legacy-encoded file names, the UTF-8 to UTF-16 conversion function tries to create valid, unique file names even for invalid UTF-8 byte sequences, so that these repositories can be checked out without error.
It is likely to be a port of something already integrated in msysgit, but at least that means the Windows version of Git won't have to diverge/patch from the main Git repo source code in order to include those improvements.
I can see that there are some problems with character encoding with git bash for windows. Less for the work with git itself and the tools it ships with (curl, cat, grep etc.). I didn't run into problems with these over the years character encoding related.
Normally with each new version problems get better resolved. E.g. with the version from a year ago, I couldn't enter characters like "ä" into the shell, so it was not possible to write
echo "ä"
To quickly test if UTF-8 is supported and at which level. A workaround is to write the byte-sequences octal:
$ echo -e "\0303\0244"
ä
Still issues I do have when I execute my windows php.exe binary to output text:
$ php -r 'echo "\xC3\xA4";'
ä
This does not give the the "ä" in the terminal, but it outputs "├ñ" instead. The workaround I have for that is, that I wrap the php command in a bash-script that processes the output through cat:
#!/bin/bash
{ php.exe "$#" 2>&1 1>&3 | cat 1>&2; } 3>&1 | cat
ref. reg. stdout + stderr cat
This magically then makes php working again:
$ php -r 'echo "\xC3\xA4";'
ä
Applies to
$ git --version
git version 1.9.4.msysgit.1
I must admit I miss deeper understanding why this is all the way it is. But I'm finally happy that I found a workaround to use php in git bash with UTF-8 support.
For me the solution was just to enable unicode support.
Docs: https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support
git config --global core.quotepath off
I found the following steps helpful:
Run Git Bash
Right-click and select Options...
Select Text group at the left
Change Font to Consolas
Select C as Locale and UTF-8 as Character set
Apply and Save.
In the terminal execute:
git config --global core.quotepath false
In rare cases, execute in the terminal as well:
export LANG='C.UTF-8'
The problem with chcp 65001 is that there are bugs in the C runtime (MSVCRT) that make stdio calls return inconsistent results when run under code page 65001.
That should be better with Git 2.23 (Q3 2019)
See commit 090d1e8 (03 Jul 2019) by Karsten Blees (kblees).
(Merged by Junio C Hamano -- gitster -- in commit 0328db0, 11 Jul 2019)
gettext: always use UTF-8 on native Windows
On native Windows, Git exclusively uses UTF-8 for console output (both with MinTTY and native Win32 Console).
Gettext uses setlocale() to determine the output encoding for translated text, however, MSVCRT's setlocale() does not support UTF-8.
As a result, translated text is encoded in system encoding (as per GetAPC()), and non-ASCII chars are mangled in console output.
Side note: There is actually a code page for UTF-8: 65001.
In practice, it does not work as expected at least on Windows 7, though, so we cannot use it in Git. Besides, if we overrode the code page, any process spawned from Git would inherit that code page (as opposed to the code page configured for the current user), which would quite possibly break e.g. diff or merge helpers.
So we really cannot override the code page.
In init_gettext_charset(), Git calls gettext's bind_textdomain_codeset() with the character set obtained via locale_charset(); Let's override that latter function to force the encoding to UTF-8 on native Windows.
In Git for Windows' SDK, there is a libcharset.h and therefore we define HAVE_LIBCHARSET_H in the MINGW-specific section in config.mak.uname, therefore we need to add the override before that conditionally-compiled code block.
Rather than simply defining locale_charset() to return the string "UTF-8", though, we are careful not to break LC_ALL=C: the ab/no-kwset patch series, for example, needs to have a way to prevent Git from expecting UTF-8-encoded input.
And:
See commit 697bdd2 (04 Jul 2019), and commit 9423885, commit 39a98e9 (27 Jun 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 0a2ff7c, 11 Jul 2019)
mingw: use Unicode functions explicitly
Many Win32 API functions actually exist in two variants: one with the A suffix that takes ANSI parameters (char * or const char *) and one with the W suffix that takes Unicode parameters (wchar_t * or const wchar_t *).
The ANSI variant assumes that the strings are encoded according to whatever is the current locale.
This is not what Git wants to use on Windows: we assume that char * variables point to strings encoded in UTF-8.
There is a pseudo UTF-8 locale on Windows, but it does not work as one might expect. In addition, if we overrode the user's locale, that would modify the behavior of programs spawned by Git (such as editors, difftools, etc), therefore we cannot use that pseudo locale.
Further, it is actually highly encouraged to use the Unicode versions
instead of the ANSI versions, so let's do precisely that.
Note: when calling the Win32 API functions without any suffix, it depends whether the UNICODE constant is defined before the relevant headers are #include'd.
Without that constant, the ANSI variants are used.
Let's be explicit and avoid that ambiguity.
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