Installation fails on Bash on Ubuntu on Windows 10

[chrisaut]

Installation fails with

$ make install
# Copying .bash_prompt to ~/.bash_prompt
cp -f ".bash_prompt" "/home/chris/.bash_prompt"
./install.bash
./install.bash: line 2: $'\r': command not found
./install.bash: line 4: syntax error near unexpected token `$'{\r''
'/install.bash: line 4: `ps1_is_installed () {
make: *** [install] Error 2

This is a line-ending issue. Doing sed -i 's/\r$//' sed -i 's/\r$//' install.bash before make install gets one step further, but then

$ make install
# Copying .bash_prompt to ~/.bash_prompt
cp -f ".bash_prompt" "/home/chris/.bash_prompt"
./install.bash
: command not found
bash: /home/chris/.bash_prompt: line 100: syntax error near unexpected token `$'{\r''
'ash: /home/chris/.bash_prompt: line 100: `function sexy_bash_prompt_get_git_branch() {
# Adding ~/.bash_prompt to ~/.bashrc
: command not found
bash: /home/chris/.bash_prompt: line 100: syntax error near unexpected token `$'{\r''
'ash: /home/chris/.bash_prompt: line 100: `function sexy_bash_prompt_get_git_branch() {
: command not found
bash: /home/chris/.bash_prompt: line 100: syntax error near unexpected token `$'{\r''
'ash: /home/chris/.bash_prompt: line 100: `function sexy_bash_prompt_get_git_branch() {
# We cannot confirm that sexy-bash-prompt has installed properly
# Please open a new terminal window to confirm

# If it has not, please run the following code:
echo ". ~/.bashrc" >> "/home/chris/.profile"
make: *** [install] Error 1

So another sed -i 's/\r$//' ~/.bash_prompt to resolve this.

It did seem to update the .bashrc correctly (added this at the end)

# Run twolfson/sexy-bash-prompt
. ~/.bash_prompt

however, mine was added multiple times (each times make install failed I guess).

So, this workaround is fine, but it would be nice to figure out how to fix this properly. I'm a bit as to where in the process invalid line breaks get introduced.

[twolfson]

I'm going to guess git is set up to automatically convert \n to \n\r when cloning. What's the output from the following command?

git config --get core.autocrlf
git config --global --get core.autocrlf

[chrisaut]

Ah, yes. Both return true

Setting it to false and running install works fine.

chris at ACSP4 in /mnt/c/src
$ git config --global core.autocrlf false
chris at ACSP4 in /mnt/c/src
$ git config --global --get core.autocrlf
false
chris at ACSP4 in /mnt/c/src
$ (cd /tmp && git clone --depth 1 https://github.com/twolfson/sexy-bash-prompt && cd sexy-bash-prompt && make install) && source ~/.bashrc
Cloning into 'sexy-bash-prompt'...
remote: Counting objects: 330, done.
remote: Compressing objects: 100% (210/210), done.
remote: Total 330 (delta 31), reused 310 (delta 30), pack-reused 0
Receiving objects: 100% (330/330), 121.31 KiB | 57.00 KiB/s, done.
Resolving deltas: 100% (31/31), done.
Checking connectivity... done.
# Copying .bash_prompt to ~/.bash_prompt
cp -f ".bash_prompt" "/home/chris/.bash_prompt"
./install.bash
# twolfson/sexy-bash-prompt installation complete!
exit 0
chris at ACSP4 in /mnt/c/src
$ git config --global core.autocrlf true
chris at ACSP4 in /mnt/c/src
$

Is there a way to temporarily force it to false as part of the install without changing the user?

Would be nice to add that to the instruction so it works for people regardless of the setting (I never changed this, and now I'm not sure if I should leave it changed to false).

[twolfson]

Cool, glad to hear we identified the source of the problem =) I can think of 2 possible solutions so far:

• See if there's a CLI flag to disable autocrlf for git
  • Needs some research
• Move to GitHub zips/tarballs
  • Should work but will need to find out what Windows offers CLI-wise for extraction

[twolfson]

Looks like git supports --config during cloning. I will open a PR for that

       --config <key>=<value>, -c <key>=<value>
           Set a configuration variable in the newly-created repository; this
           takes effect immediately after the repository is initialized, but
           before the remote history is fetched or any files checked out. The
           key is in the same format as expected by git-config(1) (e.g.,
           core.eol=true). If multiple values are given for the same key, each
           value will be written to the config file. This makes it safe, for
           example, to add additional fetch refspecs to the origin remote.

[twolfson]

Alright, #64 is opened up to patch the documentation

[chrisaut]

Nice, thanks for your help,.

Just FYI

Move to GitHub zips/tarballs 
Should work but will need to find out what Windows offers CLI-wise for extraction

You wouldn't really be dealing with windows, the bash shell on Windows 10 offers the entire Ubuntu userspace CLI. It's better not to really think of this as windows at all (though some things are not working 100% yet). Some more info here in case you're interested: https://msdn.microsoft.com/en-us/commandline/wsl/about

[twolfson]

Ah, right. I forgot about that. There have been other Windows environments before this though (e.g. Cygwin) which we have supported so it's probably best to not get too biased.

[twolfson]

This has been repaired in 0.26.5 via #64

[twolfson]

Thanks again for the bug report and quick responses