Someday I took a repo from Github with a NodeJS app to run it in Docker. It was a sample app for Hyperledger — https://github.com/IBM-Blockchain/car-lease-demo/, but it doesn’t matter much, just a bunch of scripts.
On running docker-compose up I saw that the container with the app exited. docker logs <id> showed that an error occurred on bash-script start (docker-startup.sh): set: illegal options -:
: not foundocker-startup.sh: 3: ./Scripts/docker-startup.sh:
./Scripts/docker-startup.sh: 5: set: Illegal option -
It was weird as the script’s very simple:
#!/bin/bash# Exit on first error, print all commands.
set -evnode app.js
Totally legal script, right?
All this was happening on Windows 10. But script is bash. It’s executed on Linux in Docker. So after a little googling I got the idea that the cause of the error is in line-endings.
Of cause! The script taken by Git on Windows got Windows-style line-endings — \r\n. It’s recommended to set core.autocrlf option to true on Windows. And obviously a bash script with Windows line-ending CRLF won’t work on Linux. It’s obvious when you realize it.
An interesting thing is that I had no autocrlf option specified in my global .gitconfig. It’s not mentioned that it’s true by default, it should be false — see https://git-scm.com/book/tr/v2/Customizing-Git-Git-Configuration#Formatting-and-Whitespace. The repo itself didn’t contain .gitattributes.
BTW: it’s an easy method to remember the right sequence of symbols in CRLF:
\r\nor\n\r: just remember “return” — \r\n. Found somewhere on SO.
So how to fix.
This nice tutorial from Github — https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings contains info on how to fix line-endings in an existing repository. I won’t repeat it. But key point is to prevent automatic converting LF to CRLF for scripts.
To do this put .gitattributes inside your repo and commit it:
* text=auto*.sh text eol=lf
So it’s a good idea to have .gitattributes in your repo with settings for Linux scripts even if you live on Linux. Because other people can live on Windows and run your app via Docker/VM.
To make sure that line-endings correctly were not converted check it in Far’s HEX editor.
Problems (git clone without core.autocrlf option):
Good (git clone with core.autocrlf set to false or after converting with help of .gitattributes):