env: bash\r: No such file or directory
env: bash\r: No such file or directory
env: bash\r: No such file or directory
Re: env: bash\r: No such file or directory
The error message suggests that **the script you're invoking has embedded `\r` characters**, which in turn suggests that it has **Windows-style `\r\n` line endings** (newlines) instead of the `\n`-only line endings `bash` expects.
As a **quick fix**, you can remove the `\r` chars. as follows:
```
sed $'s/\r$//' ./install.sh > ./install.Unix.sh
```
Note: The `$'...'` string is an [ANSI-C quoted string](http://www.gnu.org/software/bash/manual/bash.html#ANSI_002dC-Quoting) supported in `bash`, `ksh`, and `zsh`. It is used to ensure that the `\r` expands to an actual CR character before `sed` sees the script, because not all `sed` implementations themselves support `\r` as an escape sequence.
and then run
```
./install.Unix.sh --clang-completer
```
However, the larger question is why you've ended up with `\r\n`-style files - most likely, other files are affected, too.
Perhaps you're running **Git on Windows**, where a **typical configuration is to convert Unix-style `\n`-only line breaks to Windows-style `\r\n` line breaks on *checking files out* and re-converting to `\n`-only line breaks on *committing***.
While this ***somewhat* makes sense for *development***[1] on Windows, it **gets in the way of *installation* scenarios** like these.
To **make Git check out files with Unix-style file endings on Windows** - at least temporarily - use:
```
git config --global core.autocrlf false
```
Then run your installation commands involving `git clone` again.
To restore Git's behavior later, run `git config --global core.autocrlf true`.
[1] These days, most editors and CLIs on Windows can handle `\r\n` and `\n` newlines *interchangeably*.
As a **quick fix**, you can remove the `\r` chars. as follows:
```
sed $'s/\r$//' ./install.sh > ./install.Unix.sh
```
Note: The `$'...'` string is an [ANSI-C quoted string](http://www.gnu.org/software/bash/manual/bash.html#ANSI_002dC-Quoting) supported in `bash`, `ksh`, and `zsh`. It is used to ensure that the `\r` expands to an actual CR character before `sed` sees the script, because not all `sed` implementations themselves support `\r` as an escape sequence.
and then run
```
./install.Unix.sh --clang-completer
```
However, the larger question is why you've ended up with `\r\n`-style files - most likely, other files are affected, too.
Perhaps you're running **Git on Windows**, where a **typical configuration is to convert Unix-style `\n`-only line breaks to Windows-style `\r\n` line breaks on *checking files out* and re-converting to `\n`-only line breaks on *committing***.
While this ***somewhat* makes sense for *development***[1] on Windows, it **gets in the way of *installation* scenarios** like these.
To **make Git check out files with Unix-style file endings on Windows** - at least temporarily - use:
```
git config --global core.autocrlf false
```
Then run your installation commands involving `git clone` again.
To restore Git's behavior later, run `git config --global core.autocrlf true`.
[1] These days, most editors and CLIs on Windows can handle `\r\n` and `\n` newlines *interchangeably*.