Windows with WSL2 manual git clone installation method, wrong line endings

[Radmation]

Ran into an issue when installing via the git clone method (due to the linux apt install method not providing up-to-date ruby versions) where the end of the files lines were for windows instead of linux.

The work around was to set a flag -c core.autocrlf=false when doing the git clone, ex: git clone -c core.autocrlf=false https://github.com/rbenv/rbenv.git ~/.rbenv.

I think if the .gitattribues file gets modified to include a text eol=lf line it should help others down the line. At the very least updating the readme to include a section for Windows/WSL folks installing via the clone method would be helpful.

Side note: also when installing via the clone method, the install command did not work, so the ruby-build plugin needed to be installed manually, where the same flag is probably needed (not verified).

[mislav]

Hi, thanks for the note! I think a gitattributes file would be a nice addition if that would help WSL users. You're welcome to send a PR.

Do you know why a git clone under WSL would ever produce Windows line endings in the first place? As far as git is concerned, running under WSL should be the same as running under Linux.

[Juksefantomet]

Most likely this is when one has used Git installer for windows at one point that way wsl inherits, though i can confirm on a default Debian WSL install on windows 10, using in-wsl installed git.

installing rbenv though git clone yields:

 rbenv install 3.3.0
/usr/bin/env: ‘bash\r’: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines

I encountered this now with a working rbenv + rbenv-build already setup. i was attempting to install 3.3.0 - which did not work due to missing files, so i performed git pull within both ~/.rbenv and ~/.rbenv/plugins/rbenv-build/

and i now have this issue.

Here is my playback:

juksefantomet@DESKTOP-KRRTHPM:~$ source .bashrc
/usr/bin/env: ‘bash\r’: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
juksefantomet@DESKTOP-KRRTHPM:~$ git config --global core.autocrlf false
juksefantomet@DESKTOP-KRRTHPM:~$ cd .rbenv/
juksefantomet@DESKTOP-KRRTHPM:~/.rbenv$ git pull
Already up to date.
juksefantomet@DESKTOP-KRRTHPM:~/.rbenv$ cd
juksefantomet@DESKTOP-KRRTHPM:~$ source .bashrc
/usr/bin/env: ‘bash\r’: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
juksefantomet@DESKTOP-KRRTHPM:~$ rm .rbenv/ -R -f
juksefantomet@DESKTOP-KRRTHPM:~$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
Cloning into '/home/juksefantomet/.rbenv'...
remote: Enumerating objects: 3270, done.
remote: Counting objects: 100% (420/420), done.
remote: Compressing objects: 100% (218/218), done.
remote: Total 3270 (delta 234), reused 327 (delta 188), pack-reused 2850
Receiving objects: 100% (3270/3270), 662.28 KiB | 5.43 MiB/s, done.
Resolving deltas: 100% (2024/2024), done.
juksefantomet@DESKTOP-KRRTHPM:~$ echo 'eval "$(~/.rbenv/bin/rbenv init - bash)"' >> ~/.bashrc
juksefantomet@DESKTOP-KRRTHPM:~$ source .rbenv
-bash: source: .rbenv: is a directory
juksefantomet@DESKTOP-KRRTHPM:~$ source .bashrc
juksefantomet@DESKTOP-KRRTHPM:~$

As you can see, this kicks in directly after cloning, but when setting the git config you can see the problem is resolved.

[Juksefantomet]

Side note, this can also occur because in WSL2 as opposed to WSL1, you actually have a network drive, so that drive is actually mounted as a browsable drive in windows. That might be the cause of certain file manifests now behaving like it was windows. This was not the case in WSL1.

[mislav]

Thanks for the sleuthing! If you can check: before you've done git config --global core.autocrlf false, what was the default setting for the core.autocrlf option? You can check with

git config -l --show-origin | grep -E '(eol|crlf)'

I'm just trying to wrap my head around why would an in-WSL installed Git want to default to CRLF line endings. Did it inherit a gitconfig file from a Windows-owned network drive?