shell 脚本对编码和行结尾敏感吗？

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中的十六进纸）终止。

脚本中的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

在这种情况下，在caret表示法中或^m /code>在c逃脱符号中）不被视为空格。 Bash将Shebang（由单个马车返回字符组成）之后解释为要运行的命令/程序的名称。

• 由于没有命令名为^m ，它打印：找不到命令，
• 因为没有名称nate src^m ，它打印：没有这样的文件或目录
• 它通过安装^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文件名
 


在A 功能文本编辑器（Sublime，Notepad ++，Not Notepad）中打开文件，并将其配置为使用Unix line endings的文件，例如，使用vim，在保存之前运行以下命令：
 ：设置fileformat = unix
 

 <<） P>如果您有 sed 实用程序的版本，该实用程序支持 -i 或  - 现场选项，例如，gnu  sed ，您可以运行以下命令来剥离尾随的马车返回：

  sed -i's/\ r $ //'fileName
 
使用其他版本的 sed ，您可以使用输出重定向写入新文件。确保将其他文件名用于重定向目标（以后可以重命名）。
  sed's/\ r $ //'fileName＆gt; filename.unix
 


同样， tr 翻译过滤器可用于从其输入中删除不需要的字符：
  tr -d'\ r'＆lt; filename＆gt; filename.unix
 


 cygwin bash
带有bash端口的cygwin，有一个自定义 igncr 选项，可以将其设置为忽略线路结尾的运输返回（大概是因为其许多用户使用本机Windows程序来编辑其文本文件）。

可以通过运行 set -o igncr 来为当前 shell启用这一点。
设置此选项仅适用于 current  shell进程，因此当 sourcing 文件带有无关的托架返回时，它可以很有用。如果您定期遇到具有DOS线结尾的Shell脚本，并希望永久设置此选项，则可以设置一个称为 shellOpts （所有大写字母）的环境变量，以包括 igncr 。 Bash使用此环境变量在启动时将其设置为设置Shell选项（在读取任何启动文件之前）。
有用的实用程序
文件实用程序对于快速查看文本文件中使用了哪些线路结尾。这是针对每种文件类型打印的内容：

 unix行末尾： bourne-again as shell脚本，ascii文本可执行文件
 mac line endings： bourne-again as shell shell脚本，ascii文本可执行，带有CR行terminators 
 dos行末尾： bourne-again as shell脚本，ASCII文本可执行文件，带有CRLF行终端

  cat> cat 实用程序的GNU版本具有  -    - v， - 显示非打印字符的表 - 非打印选项。
  dos2unix 实用程序是专门编写的，用于在UNIX，MAC和DOS线结束之间转换文本文件。
有用的链接
Wikipedia具有出色的文章涵盖了标记文本线结束的许多不同方法，此类编码的历史以及如何在不同的操作系统，编程语言和Internet协议（例如FTP）中处理新线。
带有经典Mac OS线路结尾的文件，
  classic mac os （pre-os x），每行都是终止于马车返回（十进制13，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（＃）开始）作为一个评论。
注意：2001年，Apple启动了基于BSD衍生的 nextStep 操作系统操作系统的Mac OS X 。结果，OS X还使用UNIX风格的仅限LF线结尾，从那时起，用CR终止的文本文件变得极为罕见。尽管如此，我认为值得展示Bash将如何尝试解释此类文件。
 file.txt || grep -x "hello" file.txt
$

因为该行实际上以^M 结束）

没有匹配， 马车返回将光标移动到行的开始：

字符串比较将失败，即使在编写屏幕时字符串似乎是相同的：

解决方案

解决方案是将文件转换为使用Unix式的行末尾。有多种方法可以完成：

1. 使用 dos2unix 程序：

2. 在A 功能文本编辑器（Sublime，Notepad ++，Not Notepad）中打开文件，并将其配置为使用Unix line endings的文件，例如，使用vim，在保存之前运行以下命令：

3. <<） P>如果您有 sed 实用程序的版本，该实用程序支持 -i 或 - 现场选项，例如，gnu sed ，您可以运行以下命令来剥离尾随的马车返回：

   使用其他版本的 sed ，您可以使用输出重定向写入新文件。确保将其他文件名用于重定向目标（以后可以重命名）。

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

cygwin bash

带有bash端口的cygwin，有一个自定义 igncr 选项，可以将其设置为忽略线路结尾的运输返回（大概是因为其许多用户使用本机Windows程序来编辑其文本文件）。
可以通过运行 set -o igncr 来为当前 shell启用这一点。

设置此选项仅适用于 current shell进程，因此当 sourcing 文件带有无关的托架返回时，它可以很有用。如果您定期遇到具有DOS线结尾的Shell脚本，并希望永久设置此选项，则可以设置一个称为 shellOpts （所有大写字母）的环境变量，以包括 igncr 。 Bash使用此环境变量在启动时将其设置为设置Shell选项（在读取任何启动文件之前）。

有用的实用程序

文件实用程序对于快速查看文本文件中使用了哪些线路结尾。这是针对每种文件类型打印的内容：

• unix行末尾： bourne-again as shell脚本，ascii文本可执行文件
• mac line endings： bourne-again as shell shell脚本，ascii文本可执行，带有CR行terminators
• dos行末尾： bourne-again as shell脚本，ASCII文本可执行文件，带有CRLF行终端

cat> cat 实用程序的GNU版本具有 - - v， - 显示非打印字符的表 - 非打印选项。

dos2unix 实用程序是专门编写的，用于在UNIX，MAC和DOS线结束之间转换文本文件。

有用的链接

Wikipedia具有出色的文章涵盖了标记文本线结束的许多不同方法，此类编码的历史以及如何在不同的操作系统，编程语言和Internet协议（例如FTP）中处理新线。

带有经典Mac OS线路结尾的文件，

classic mac os （pre-os x），每行都是终止于马车返回（十进制13，ASCII中的十六进制）。如果脚本文件用这样的行结尾保存，BASH只会看到一条长行：

因为这条长线以Octothorpe（＃）开始）作为一个评论。

注意：2001年，Apple启动了基于BSD衍生的 nextStep 操作系统操作系统的Mac OS X 。结果，OS X还使用UNIX风格的仅限LF线结尾，从那时起，用CR终止的文本文件变得极为罕见。尽管如此，我认为值得展示Bash将如何尝试解释此类文件。

Answer 2

在 JetBrains 产品（PyCharm、PHPStorm、IDEA 等）中，您需要单击 CRLF/LF 在两者之间切换行分隔符的类型（\r\n 和 \n）。

Answer 3

我试图从 Windows 启动我的 Docker 容器，结果发现：

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

我正在使用 Git Bash，问题出在 Git 配置上，然后我执行了以下步骤，结果成功了。它将配置 Git 在签出时不转换行结尾：

1. git config --global core.autocrlf input
2. 删除本地存储库
3. 并再次克隆它。

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

在此之前，我尝试过这个，但不起作用：

1. dos2unix scriptname.sh
2. sed -i -e 's/\r$//' scriptname.sh
3. sed -i -e 's/^M$//' 脚本名。嘘

Answer 4

如果您使用的读取将从线的开头和结尾修剪空格。如果您告诉它，马车返回是空格的（通过将它们添加到 ifs 变量中），它将从线的末端修剪它们。

在bash（或zsh或ksh）中，这意味着您要替换此标准成语：（

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

注意： -r 选项与此

IFS=
无关，这通常是一个好主意避免撞击。）
如果您不使用 ifs = 前缀（例如，因为要将数据拆分为字段），那么您将替换以下：
read -r field1 field2 ...    # This will not trim CR

如果您正在使用：
IFS=
如果您正在使用不支持 $'...''引用模式的外壳（例如，dash，某些Linux发行版上的默认/bin/sh），或者您的脚本甚至可能用这样的外壳运行，然后您需要变得更加复杂：
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

无关，这通常是一个好主意避免撞击。）
如果您不使用 ifs = 前缀（例如，因为要将数据拆分为字段），那么您将替换以下：

如果您正在使用：

如果您正在使用不支持 $'...''引用模式的外壳（例如，dash，某些Linux发行版上的默认/bin/sh），或者您的脚本甚至可能用这样的外壳运行，然后您需要变得更加复杂：

请注意，通常，当您更改 ifs 时，应该尽快将其放回正常状态以避免奇怪的副作用;但是，在所有这些情况下，它都是 read 命令的前缀，因此它仅影响一个命令，而不必在之后重置。
 \t\n\r' read -r field1 field2 ...    # This *will* trim CR

如果您正在使用不支持 $'...''引用模式的外壳（例如，dash，某些Linux发行版上的默认/bin/sh），或者您的脚本甚至可能用这样的外壳运行，然后您需要变得更加复杂：

请注意，通常，当您更改 ifs 时，应该尽快将其放回正常状态以避免奇怪的副作用;但是，在所有这些情况下，它都是 read 命令的前缀，因此它仅影响一个命令，而不必在之后重置。

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

无关，这通常是一个好主意避免撞击。）

如果您不使用 ifs = 前缀（例如，因为要将数据拆分为字段），那么您将替换以下：

如果您正在使用：

如果您正在使用不支持 $'...''引用模式的外壳（例如，dash，某些Linux发行版上的默认/bin/sh），或者您的脚本甚至可能用这样的外壳运行，然后您需要变得更加复杂：

请注意，通常，当您更改 ifs 时，应该尽快将其放回正常状态以避免奇怪的副作用;但是，在所有这些情况下，它都是 read 命令的前缀，因此它仅影响一个命令，而不必在之后重置。

Answer 5

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

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

Answer 6

来自重复项，如果问题是您的文件名称末尾包含^M，您可以将它们重命名为“

for f in *
您正确地想要修复导致这些文件的任何原因”首先要使用损坏的名称（可能创建它们的脚本应该进行 dos2unix 编辑，然后重新运行？），但有时这是不可行的。
 $'\r' 语法是 Bash 特定的；如果您有不同的外壳，也许您需要使用其他符号。也许另请参阅 sh 和 bash 之间的区别
\r'; do
    mv "$f" "${f%
您正确地想要修复导致这些文件的任何原因”首先要使用损坏的名称（可能创建它们的脚本应该进行 dos2unix 编辑，然后重新运行？），但有时这是不可行的。
 $'\r' 语法是 Bash 特定的；如果您有不同的外壳，也许您需要使用其他符号。也许另请参阅 sh 和 bash 之间的区别
\r'}"
done

您正确地想要修复导致这些文件的任何原因”首先要使用损坏的名称（可能创建它们的脚本应该进行 dos2unix 编辑，然后重新运行？），但有时这是不可行的。

$'\r' 语法是 Bash 特定的；如果您有不同的外壳，也许您需要使用其他符号。也许另请参阅 sh 和 bash 之间的区别

Answer 7

当我将 git 与 WSL 结合使用时，我遇到了这个问题。
git 有一个功能，它可以根据您使用的操作系统更改文件的行结尾，在 Windows 上，它确保行结尾为 \r\n ，这与仅使用 Linux 的 Linux 不兼容<代码>\n。

您可以通过将文件名 .gitattributes 添加到 git 根目录并添加如下行来解决此问题：

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

在此示例中，config 目录中的所有文件都只有行- feed 行结尾和 run.sh 文件也是如此。

Answer 8

大量参考 git，但没有重新规范化行结尾。只需转到存储库的根目录并运行：

git add --renormalize .

仅重新签入需要刷新行结尾的文件。文件看起来没有任何更改，因为行结尾是不可见的。

Answer 9

对于记事本++用户，可以通过： edit ＆gt; eol conversion ＆gt; 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脚本的解决方案： file ＆gt; 线分离器
使用 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'`