外壳脚本对编码和线路结尾敏感吗？

Question

我正在MacOS上制作NW.JS应用，并希望以Dev模式运行该应用程序 通过双击图标。 在第一步中，我正在尝试使我的shell脚本起作用。

在Windows上使用VS代码（我想获得时间），我在项目的根部创建了一个run-nw文件，其中包含

#!/bin/bash

cd "src"
npm install

cd ..
./tools/nwjs-sdk-v0.17.3-osx-x64/nwjs.app/Contents/MacOS/nwjs "src" &

内容

$ sh ./run-nw

: command not found  
: No such file or directory  
: command not found  
: No such file or directory  

Usage: npm <command>

where <command> is one of:  (snip commands list)

(snip npm help)

[email protected] /usr/local/lib/node_modules/npm  
: command not found  
: No such file or directory  
: command not found

以下 理解。

• 看来它作为命令为空行。 在我的编辑器（VS代码）中，我尝试用\ r \ n \ n替换 （如果\ r会产生问题），但没有任何改变。
• 看来它找不到文件夹 （有或没有dirname指令）， 也许它不知道cd命令？
• 看来它不了解安装参数到npm。
• 真正奇怪我的部分是它仍然运行该应用程序 （如果我手动进行npm安装）...

无法使其正常工作，并怀疑有些奇怪的东西 该文件本身，我这次使用VIM直接在Mac上创建了一个新的。 我输入了完全相同的说明，...现在它可以使用 问题。
两个文件上的diff揭示了零差。

有什么区别？什么可以使第一个脚本不起作用？我怎么知道？

进行更新

在被接受的答案的建议之后，在错误的行之后 结局回来了，我检查了多件事。 事实证明，由于我从Windows复制了〜/.gitConfig 机器，我有autocrlf = true，所以每次修改bash 在Windows下的文件，它将行末尾重新设置为\ r \ n。
因此，除了运行dos2unix（您必须 在Mac上使用HomeBrows安装），如果您使用的是Git，请检查您的 .gitConfig文件。

Answer 1

是的。 Bash 脚本对行结束敏感，无论是在脚本本身还是在它处理的数据中。它们应该具有 Unix 风格的行结尾，即每行都以换行符（十进制 10，ASCII 中十六进制 0A）结束。

脚本中的 DOS/Windows 行结尾

对于 Windows 或 DOS 样式的行结尾，每行都以回车符后跟换行符结束。您可以在 cat -v yourfile 的输出中看到这个原本不可见的字符：

$ cat -v yourfile
#!/bin/bash^M
^M
cd "src"^M
npm install^M
^M
cd ..^M
./tools/nwjs-sdk-v0.17.3-osx-x64/nwjs.app/Contents/MacOS/nwjs "src" &^M

在本例中，回车符（脱字符号中的 ^M 或 \r< C 转义符号中的 /code> ）不被视为空格。 Bash 将 shebang 之后的第一行（由单个回车符组成）解释为要运行的命令/程序的名称。

• 由于没有名为 ^M 的命令，因此会打印 : command not find
• 由于没有名为 src^M 的目录，因此会打印 ：没有这样的文件或目录
• 它将install^M而不是install作为参数传递给npm，这会导致npm 来抱怨。

输入数据中的 DOS/Windows 行结尾

像上面一样，如果您有一个带有回车符的输入文件：

hello^M
world^M

那么它在编辑器中以及将其写入屏幕时看起来完全正常，但工具可能会产生奇怪的结果。例如，grep 将无法找到明显存在的行：（

$ grep 'hello
不匹配，因为该行实际上以 ^M 结尾）
附加文本似乎会覆盖该行，因为回车将光标移至行首：
$ sed -e 's/$/!/' file.txt
!ello
!orld

即使字符串在写入屏幕时看起来相同，字符串比较也会失败：
$ a="hello"; read b < file.txt
$ if [[ "$a" = "$b" ]]
  then echo "Variables are equal."
  else echo "Sorry, $a is not equal to $b"
  fi

Sorry, hello is not equal to hello

解决方案
解决方案是将文件转换为使用 Unix 样式的行结尾。有多种方法可以实现此目的：


使用 dos2unix 程序：
dos2unix 文件名



在可用文本编辑器（Sublime、Notepad++，而不是记事本）中打开文件，并将其配置为保存带有 Unix 行结尾的文件，例如，使用 Vim，在（重新）保存之前运行以下命令：
:设置文件格式=unix


 < p>如果您有支持 -i 或 --in-place 选项的 sed 实用程序版本，例如 GNU sed，你可以运行以下命令去除尾随回车符：

sed -i 's/\r$//' 文件名

使用其他版本的 sed，您可以使用输出重定向来写入新文件。请务必为重定向目标使用不同的文件名（稍后可以重命名）。
sed 's/\r$//' 文件名 >文件名.unix



同样，tr 翻译过滤器可用于从其输入中删除不需要的字符：
tr -d '\r' <文件名>文件名.unix



 Cygwin Bash
通过 Cygwin 的 Bash 端口，有一个自定义 igncr 选项，可以设置为忽略行结尾中的回车符（大概是因为许多用户使用本机 Windows 程序来编辑其文本文件）。

可以通过运行 set -o igncr 为当前 shell 启用此功能。
设置此选项仅适用于当前 shell 进程，因此在获取带有无关回车符的文件时非常有用。如果您经常遇到以 DOS 行结尾的 shell 脚本，并且希望永久设置此选项，则可以设置一个名为 SHELLOPTS（全部大写字母）的环境变量来包含 igncr。 Bash 使用此环境变量在启动时（在读取任何启动文件之前）设置 shell 选项。
有用的实用程序
file 实用程序对于快速查看文本文件中使用了哪些行结尾非常有用。以下是它为每种文件类型打印的内容：

 Unix 行结尾：Bourne-Again shell 脚本，ASCII 文本可执行文件
 Mac 行结尾：Bourne-Again shell 脚本，ASCII 文本可执行文件，带 CR 行终止符
 DOS 行结束符：Bourne-Again shell 脚本，ASCII 文本可执行文件，带有 CRLF 行终止符

 GNU 版本cat 实用程序有一个 -v, --show-nonprinting 选项，用于显示非打印字符。
 dos2unix 实用程序是专门为在 Unix、Mac 和 DOS 行结尾之间转换文本文件而编写的。
有用的链接
维基百科有一篇优秀文章，涵盖了标记文本行结尾的多种不同方式、此类编码的历史以及不同操作系统、编程语言和 Internet 协议（例如 FTP）中如何处理换行符。
具有经典 Mac OS 行结尾的文件
对于 经典 Mac OS（OS X 之前的版本），每一行都是以回车符结束（十进制 13，十六进制 0D，ASCII 码）。如果以这样的行结尾保存脚本文件，Bash 只会看到如下所示的一长行：
#!/bin/bash^M^Mcd "src"^Mnpm install^M^Mcd ..^M./tools/nwjs-sdk-v0.17.3-osx-x64/nwjs.app/Contents/MacOS/nwjs "src" &^M

由于这一长行以 octothorpe (#) 开头，Bash 会处理该行（以及整个文件） ）作为单个评论。
注：2001 年，Apple 推出了 Mac OS X，它基于 BSD 衍生的 NeXTSTEP 操作系统。因此，OS X 也使用 Unix 风格的仅 LF 行结尾，从那时起，以 CR 结尾的文本文件变得极其罕见。尽管如此，我认为有必要展示 Bash 如何尝试解释此类文件。
 file.txt || grep -x "hello" file.txt
$

不匹配，因为该行实际上以 ^M 结尾）

附加文本似乎会覆盖该行，因为回车将光标移至行首：

即使字符串在写入屏幕时看起来相同，字符串比较也会失败：

解决方案

解决方案是将文件转换为使用 Unix 样式的行结尾。有多种方法可以实现此目的：

1. 使用 dos2unix 程序：

2. 在可用文本编辑器（Sublime、Notepad++，而不是记事本）中打开文件，并将其配置为保存带有 Unix 行结尾的文件，例如，使用 Vim，在（重新）保存之前运行以下命令：

3. < p>如果您有支持 -i 或 --in-place 选项的 sed 实用程序版本，例如 GNU sed，你可以运行以下命令去除尾随回车符：

   使用其他版本的 sed，您可以使用输出重定向来写入新文件。请务必为重定向目标使用不同的文件名（稍后可以重命名）。

4. 同样，tr 翻译过滤器可用于从其输入中删除不需要的字符：

Cygwin Bash

通过 Cygwin 的 Bash 端口，有一个自定义 igncr 选项，可以设置为忽略行结尾中的回车符（大概是因为许多用户使用本机 Windows 程序来编辑其文本文件）。
可以通过运行 set -o igncr 为当前 shell 启用此功能。

设置此选项仅适用于当前 shell 进程，因此在获取带有无关回车符的文件时非常有用。如果您经常遇到以 DOS 行结尾的 shell 脚本，并且希望永久设置此选项，则可以设置一个名为 SHELLOPTS（全部大写字母）的环境变量来包含 igncr。 Bash 使用此环境变量在启动时（在读取任何启动文件之前）设置 shell 选项。

有用的实用程序

file 实用程序对于快速查看文本文件中使用了哪些行结尾非常有用。以下是它为每种文件类型打印的内容：

• Unix 行结尾：Bourne-Again shell 脚本，ASCII 文本可执行文件
• Mac 行结尾：Bourne-Again shell 脚本，ASCII 文本可执行文件，带 CR 行终止符
• DOS 行结束符：Bourne-Again shell 脚本，ASCII 文本可执行文件，带有 CRLF 行终止符

GNU 版本cat 实用程序有一个 -v, --show-nonprinting 选项，用于显示非打印字符。

dos2unix 实用程序是专门为在 Unix、Mac 和 DOS 行结尾之间转换文本文件而编写的。

有用的链接

维基百科有一篇优秀文章，涵盖了标记文本行结尾的多种不同方式、此类编码的历史以及不同操作系统、编程语言和 Internet 协议（例如 FTP）中如何处理换行符。

具有经典 Mac OS 行结尾的文件

对于 经典 Mac OS（OS X 之前的版本），每一行都是以回车符结束（十进制 13，十六进制 0D，ASCII 码）。如果以这样的行结尾保存脚本文件，Bash 只会看到如下所示的一长行：

由于这一长行以 octothorpe (#) 开头，Bash 会处理该行（以及整个文件） ）作为单个评论。

注：2001 年，Apple 推出了 Mac OS X，它基于 BSD 衍生的 NeXTSTEP 操作系统。因此，OS X 也使用 Unix 风格的仅 LF 行结尾，从那时起，以 CR 结尾的文本文件变得极其罕见。尽管如此，我认为有必要展示 Bash 如何尝试解释此类文件。

Answer 2

在Jetbrains产品（Pycharm，PhpStorm，Idea等）中，您需要单击CRLF/lf to tokgle 行分隔符的类型（\ r \ n和\ n）。

Answer 3

我试图从Windows启动我的Docker容器，并得到了：

Bash script and /bin/bash^M: bad interpreter: No such file or directory

我正在使用Git Bash，而问题是Git Config，然后我只是在下面做了下面的步骤并起作用。它将配置git以不转换结帐时的行末尾：

1. git config - global core.autocrlf输入
2. 再次删除您的本地存储库克隆
3. 。

非常感谢Jason Harmon在此链接中：
https：//forums.docker。 com/t/erry-while-while-docker-code-in-powershell/34059/6

在此之前，我尝试过，这是不起作用的：

1. dos2unix scriptname.sh
2. <代码> sed -i -e's/\ r $ //'scriptname.sh
3. sed -i -e's/^m $ // scriptname.sh

Answer 4

如果您使用read命令从DOS/Windows格式（或可能）的文件（或管道）中读取数据，您可以利用事实上，read 会修剪行首和行尾的空格。如果您告诉它回车符是空格（通过将它们添加到 IFS 变量），它会从行尾删除它们。

在 bash（或 zsh 或 ksh）中，这意味着您可以将此标准习惯用法：替换

IFS= read -r somevar    # This will not trim CR

为：（

IFS=
注意：-r选项与此无关，通常是一个好主意避免损坏反斜杠。）
如果您不使用 IFS= 前缀（例如，因为您想将数据拆分为字段），那么您可以将以下内容替换
read -r field1 field2 ...    # This will not trim CR

为：
IFS=
如果您使用一个没有的外壳支持 $'...' 引用模式（例如，破折号，某些 Linux 发行版上的默认 /bin/sh），或者您的脚本甚至可能以这样的方式运行shell，那么你需要变得更复杂一点：
cr="$(printf '\r')"
IFS="$cr" read -r somevar    # Read trimming *only* CR
IFS="$IFS$cr" read -r field1 field2 ...    # Read trimming CR and whitespace, and splitting fields

注意，通常情况下，当你改变IFS时，你应该尽快将其恢复正常，以避免奇怪的副作用；但在所有这些情况下，它都是 read 命令的前缀，因此它只影响该命令，并且之后不必重置。
\r' read -r somevar    # This *will* trim CR

注意：-r选项与此无关，通常是一个好主意避免损坏反斜杠。）
如果您不使用 IFS= 前缀（例如，因为您想将数据拆分为字段），那么您可以将以下内容替换

为：

如果您使用一个没有的外壳支持 $'...' 引用模式（例如，破折号，某些 Linux 发行版上的默认 /bin/sh），或者您的脚本甚至可能以这样的方式运行shell，那么你需要变得更复杂一点：

注意，通常情况下，当你改变IFS时，你应该尽快将其恢复正常，以避免奇怪的副作用；但在所有这些情况下，它都是 read 命令的前缀，因此它只影响该命令，并且之后不必重置。
 \t\n\r' read -r field1 field2 ...    # This *will* trim CR

如果您使用一个没有的外壳支持 $'...' 引用模式（例如，破折号，某些 Linux 发行版上的默认 /bin/sh），或者您的脚本甚至可能以这样的方式运行shell，那么你需要变得更复杂一点：

注意，通常情况下，当你改变IFS时，你应该尽快将其恢复正常，以避免奇怪的副作用；但在所有这些情况下，它都是 read 命令的前缀，因此它只影响该命令，并且之后不必重置。

\r' read -r somevar # This *will* trim CR

注意：-r选项与此无关，通常是一个好主意避免损坏反斜杠。）

如果您不使用 IFS= 前缀（例如，因为您想将数据拆分为字段），那么您可以将以下内容替换

为：

如果您使用一个没有的外壳支持 $'...' 引用模式（例如，破折号，某些 Linux 发行版上的默认 /bin/sh），或者您的脚本甚至可能以这样的方式运行shell，那么你需要变得更复杂一点：

注意，通常情况下，当你改变IFS时，你应该尽快将其恢复正常，以避免奇怪的副作用；但在所有这些情况下，它都是 read 命令的前缀，因此它只影响该命令，并且之后不必重置。

Answer 5

由于正在使用 VS Code，我们可以在右下角看到 CRLF 或 LF，具体取决于所使用的内容，如果单击它，我们可以在它们之间进行更改（在下面的示例中使用 LF）：

我们还可以使用命令托盘中的“更改行尾序列”命令。因为它们的功能相同，所以更容易记住。

Answer 6

来自副本，如果问题是您有 name 包含^m的文件，则可以

for f in *
正确地 将它们重命名首先要打破名称（可能是创建它们的脚本应该是 dos2unix  ed，然后重新运行吗？）但是有时这是不可行的。
  $'\ r'语法是bash特定的；如果您有不同的外壳，也许您需要使用其他符号。也许还请参见 SH和Bash之间的差异
\r'; do
    mv "$f" "${f%
正确地 将它们重命名首先要打破名称（可能是创建它们的脚本应该是 dos2unix  ed，然后重新运行吗？）但是有时这是不可行的。
  $'\ r'语法是bash特定的；如果您有不同的外壳，也许您需要使用其他符号。也许还请参见 SH和Bash之间的差异
\r'}"
done

正确地 将它们重命名首先要打破名称（可能是创建它们的脚本应该是dos2unix ed，然后重新运行吗？）但是有时这是不可行的。

$'\ r'语法是bash特定的；如果您有不同的外壳，也许您需要使用其他符号。也许还请参见 SH和Bash之间的差异

Answer 7

当我将git与WSL一起使用时，我遇到了这个问题。
git具有一个功能，可以根据您使用的操作系统更改文件的线路结束，在窗口上，请确保行结尾为\ r \ n，它与Linux不兼容，该>仅使用它\ n。

您可以通过在git root目录中添加文件名来解决此问题，并添加行如下：

config/* text eol=lf
run.sh text eol=lf

在此示例中，所有文件config> config> config目录只有行 -进纸线结束和run.sh文件。

Answer 8

大量引用git，但不能重新统治到位的线路结尾。只需转到您的存储库并运行的根源：

git add --renormalize .

只需重新检查需要刷新线末端的文件即可。似乎文件没有更改，因为行终点是看不见的。

Answer 9

对于Notepad++用户，可以通过以下方式解决：编辑> EOL 转换 > Unix (LF)

Answer 10

摆脱不需要的CR（'\ r'）字符的另一种方法是运行tr命令，例如：

$ tr -d '\r' < dosScript.py > nixScript.py

Answer 11

Mac / Linux上的最简单方法 - 使用“ touch”命令创建文件，使用VI或VIM编辑器打开此文件，粘贴您的代码并保存。这将自动删除Windows字符。

Answer 12

如果您使用的是像BBEDIT这样的文本编辑器，则可以在状态栏上进行。有一个选择可以切换。

）

Answer 13

脚本可以互相打电话。
一个更好的魔术解决方案是将文件夹/子文件夹中的所有脚本转换：

find . -name "*.sh" -exec sed -i -e 's/\r$//' {} +

您也可以使用dos2unix，但是默认情况下，许多服务器都没有安装它。

Answer 14

与这个问题相比，我曾多次损坏Bash脚本。

关于如何更改文件的解决方案已经发布了许多解决方案。
不过，我在内置的VIM方法上没有看到任何执行此任务的方法。

使用shell脚本打开vim并运行此命令

:set ff=unix

，然后编辑您的.gitAttributes以获取永久修复程序

Answer 15

对于IntelliJ用户，这里是编写Linux脚本的解决方案：文件> 行分隔符
使用 LF - Unix 和 macOS (\n)

Answer 16

以防万一，如果您（像我一样）需要一个可在 Windows 中编辑但可在 Linux 中运行的脚本（因此该脚本可能有 CRLF，并且我们不能有 2 个版本，一个用于 Linux，另一个用于 Windows），我来到了在Linux中运行脚本的方式如下（./build.sh是脚本）

sed -e 's/\r$//' ./build.sh | bash

Answer 17

如果您收到错误消息

/usr/bin/env: 'bash\r': 没有这样的文件或目录

这通常是因为您调用的脚本嵌入了 \r 字符，这反过来表明它具有 Windows 风格的 \r\n 行结尾（换行符），而不是 bash 期望的仅 \n 行结尾

您需要“重置”环境变量以确保您使用默认环境设置。这可以通过在终端中运行以下命令来完成：

source /etc/profile
source ~/.bashrc
source ~/.profile

您可以通过打开终端来运行这些命令，或者如果您使用的是 WSL，则可以通过连接到 WSL 实例来执行命令。

Answer 18

为了完整，我指出另一种解决方案可以永久解决此问题而无需始终运行DOS2Unix：

sudo ln -s /bin/bash `printf 'bash\r'`