Line endings with Git

Question

I have setup a Jenkins job which will execute a build.sh from my repository. The job starts and exits with the following error:

d:\jenkins\workspace\test-win7>c:\cygwin64\bin\bash.exe -xe build.sh + $'\r' build.sh: line 2: $'\r': command not found

I found out that this occurs because of a problem with line endings. I have written my build.sh in Notepad++ with CRLF endings. And I used a .gitattributes file with the following options but none of them work. I also saved my file with LF endings and committed them but still this error wont go away. Could anyone be kind enough to explain to me how this line endings system work? What setting should I keep in my .gitattributes file so that my builds run on Jenkins AND my friends who pull from my Repo are not affected.

• *.sh text eol=crlf
• * text=auto
• *.sh text eol=lf

My jenkins build node is a windows node. I do my development in Eclipse in a Windows local machine.

Answer 1

Just put directly the eol to unix style for your .sh files.

Even if your building environment is on windows, you are using a cygwin environment right? Anyway, windows command interpreter cmd.exe can not understand shell scripts in the first place, so you don't have to worry about windows carriage return.

Optionally, you can configure the way Git manages line endings on a per-repository basis by configuring a special .gitattributes file. This file is committed into the repository and overrides an individual's core.autocrlf setting, ensuring consistent behavior for all users, regardless of their Git settings. The advantage of a .gitattributes file is that your line configurations are associated with your repository. You don't need to worry about whether or not collaborators have the same line ending settings that you do.

The .gitattributes file must be created in the root of the repository and committed like any other file.

A .gitattributes file looks like a table with two columns:

On the left is the file name for Git to match. On the right is the line ending configuration that Git should use for those files.

Here's an example .gitattributes file. You can use it as a template for your repositories:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

You'll notice that files are matched--*.c, *.sln, *.png--, separated by a space, then given a setting--text, text eol=crlf, binary. We'll go over some possible settings below.

text=auto Git will handle the files in whatever way it thinks is best. This is a good default option. text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux. text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows. binary Git will understand that the files specified are not text, and it should not try to change them. The binary setting is also an alias for -text -diff.

Source: https://help.github.com/articles/dealing-with-line-endings/ Additional readings: How to change line-ending settings