Question

我已经设置了Jenkins作业，该作业将从我的存储库中执行build.sh。作业开始和退出时出现以下错误：

d：\ jenkins \ workspace \ test-win7＆gt; c：\ cygwin64 \ bin \ bash.exe -xe build.sh + $'\ r' build.sh：第2行：$'\ r'：找不到命令

我发现这是因为行结尾的问题而发生的。我在Notepad ++中用CRLF结尾编写了build.sh。我使用了一个带有以下选项的.gitattributes文件，但它们都不起作用。我还用LF结尾保存了我的文件并提交了它们但是这个错误仍然不会消失。有谁可以善意向我解释这条线结束系统是如何工作的？我应该在.gitattributes文件中保留哪些设置，以便我的构建在Jenkins上运行，而从我的Repo中提取的朋友不受影响。

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

我的jenkins构建节点是一个Windows节点。我在Windows本地机器上进行Eclipse开发。

Answer 1

直接将eol直接放入.sh文件的unix样式。

即使您的建筑环境是在Windows上，您正在使用cygwin环境吗？无论如何，Windows命令解释器cmd.exe首先无法理解shell脚本，因此您不必担心窗口回车。

或者，您可以配置Git管理线路结尾的方式   通过配置特殊的.gitattributes文件，以每个存储库为基础。   此文件已提交到存储库并覆盖   个人core.autocrlf设置，确保一致的行为   所有用户，无论他们的Git设置如何。一个的优点   .gitattributes文件是您的线路配置相关联的   与您的存储库。你不需要担心是否   协作者具有与您相同的行结束设置。

必须在存储库的根目录中创建.gitattributes文件   和任何其他文件一样承诺。

.gitattributes文件看起来像一个包含两列的表：

左边是要匹配的Git的文件名。在右边是   Git应该用于那些文件的行结束配置。

这是一个示例.gitattributes文件。您可以将其用作模板   对于您的存储库：
# 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
您会注意到文件已匹配--*.c, *.sln, *.png--，已分开   通过空格，然后给出设置--text, text eol=crlf, binary。我们＆＃39; 11   请查看下面的一些可能的设置。

text=auto Git将以其认为最好的方式处理文件。   这是一个很好的默认选项。 text eol=crlf Git将永远转换   结账时行结尾CRLF。你应该将它用于那些文件   即使在OSX或Linux上，也必须保留CRLF个结尾。 text eol=lf Git会   在结账时始终将行结尾转换为LF。你应该用这个   即使在Windows上也必须保留LF结尾的文件。二进制Git会   了解指定的文件不是文本，也不应该   试着改变它们。二进制设置也是-text的别名   -diff。

来源： https://help.github.com/articles/dealing-with-line-endings/ 其他读物： How to change line-ending settings

Git

1 个答案: