Bug? BashOnWindows appears to convert all files to CRLF on windows volumes

[cbuschardt]

Is this by design? Ideally, we'd have control over this directly.

Some side effects:

1. dos2unix on a file in /mnt/c does nada
2. git clone on a repo produces CRLF line endings [and the shell scripts in the repo fail to run due to line endings]

[sunjoong]

git clone on a repo produces CRLF line endings

@cbuschardt - Well... Quote from https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

Formatting and Whitespace
Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git has a few configuration options to help with these issues.

core.autocrlf
If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true

If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf input

This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.

If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:

$ git config --global core.autocrlf false

[therealkenc]

Also dos2unix works fine on DrvFs (/mnt/c). WSL (a kernel API) doesn't know how lines are terminated. In fact, it doesn't know the file has lines.

[sunilmut]

@cbuschardt - Thanks for your post. git clone should not be behaving any differently than how it behaves in Linux. Are you seeing difference in behavior? If so, can you share the repro steps?

[emulvihill]

It seems to me, as a developer on Windows I will often want my WSL to check out as CRLF so native Windows editors can safely edit. Others might want to configure it differently. But as it was stated, this hurts shell scripts. It would be best if Bash was able to cope with both line ending scenarios, is there a configuration for this?
edit: People are recommending: bash <(dos2unix < yourscript) for this.

[therealkenc]

Your edit is the standard approach. Cygwin's set -o igncr was never upstreamed to mainline (or never accepted, I don't know which). Patch is here.

[therealkenc]

Closing as linux-behavior; people suffer the same general grief with VMs and folder shares. It would be nice if Cygwin's set -o igncr was upstreamed but that isn't a WSL actionable.

[alexcohn]

as a developer on Windows I will often want my WSL to check out as CRLF so native Windows editors can safely edit

It's pretty hard to find a Windows editor these days that will have problems with Unix-style text.
On the other hand, very few tools in Linux are sensitive to Windows-style line endings, bash being the only example that yours truly has ever actually encountered recently.

The bottom line, adding this to .gitattribute saved me:

*.sh text eol=lf

[ShrykeAbysmal]

Microsoft Code has endless problems with this even after setting the default line ending character at application, workspace, and folder level to \n (LF). Running a shell script in Windows/Ubuntu bash windows still throws the \r'' error constantly.

[Alexufo]

@ShrykeAbysmal have you solved issue?