以新用户身份在 Ubuntu 中运行脚本时的 Shell 问题答案

【问题标题】：Shell problems when running scripts in Ubuntu as new user以新用户身份在 Ubuntu 中运行脚本时的 Shell 问题
【发布时间】：2011-05-04 04:22:04
【问题描述】：

当我通过 SSH 登录到特定的 Ubuntu Linux（10.04 64 位）主机时，我得到了一个 bash shell。从这里我可以运行一个特定的 Python 脚本，并设置了可执行位，它的第一行是：

#!/usr/bin/env python

但是，如果另一个（新）用户通过 SSH 登录到同一主机并尝试运行此（或此脚本的副本），他们会收到以下错误：

$ ./script.py
: No such file or directory

原来这个文件实际上是一个 DOS 行结束文件，但我可以从我的登录中运行它。如果我把它转成 UNIX 格式，那么其他人也可以正常运行。

无论 DOS/UNIX 格式如何，如果我们在脚本前面加上“python”前缀，脚本对我们双方都可以正常运行：

$ python ./script.py
blah blah blah...

此外，一旦脚本转换为 UNIX 格式并且其他用户可以运行它，它仍然不能从 Makefile 运行 - make 显示与上述相同的错误。

我读到 /bin/sh 是 Ubuntu 中的“破折号”（不是“bash”）外壳，我想知道这是否与此有关，因为它的行为与 bash 不同。如果是这样，我想知道我的登录名（它工作得非常好并且已经做了多年）和这个新用户的登录名之间有什么区别，它显示了各种奇怪的行为。从哪里开始寻找？

也可能相关 - 新用户是由 Like 服务（一个 Active Directory 集成客户端）自动创建的，该服务可能以某种方式错误地配置了新用户。

我也尝试将第一行更改为 #!/usr/bin/python 没有任何区别。

两个用户都运行 bash shell 作为他们的登录 shell。

【问题讨论】：

您是否安装了/usr/bin/env？ /usr/bin/env python 是否从命令行运行？此外，shell 的名称是“bash”。
@S.Lott：一个的shell被命名为“bash”。 OP 指的是 Ubuntu 系统上的默认提供程序 sh，即 Debian Almquist SHell (dash)。
尝试了第三个用户，也是新用户（所以同样创建了一个不同名称的新帐户），这个没有问题。这个问题似乎是第一个新用户的问题。
@S.Lott：是的，/usr/bin/env 已安装，并且 /usr/bin/env python 确实从命令行运行。顺便说一句，在 Ubuntu 中有两个常用的 shell - bash 通常是登录 shell，而 dash 通常是 'sh' shell。
@meowsqueak：请不要发表评论。请更新您的问题以包含所有事实。

标签： python linux shell ubuntu dos

【解决方案1】：

我遇到了同样的问题，从上面的答案中并没有立即清楚问题是什么，或者解决方案是什么，但是我想我现在明白了。

显然 windows 换行符的编码略有不同。虽然 cygwin 可以以 unix 格式编码，但我使用的是 windows 文本编辑器 (Notepad++) 来编写我的脚本，默认格式是 windows CRLF 编码。 Notepad++ 可以为 unix 重新配置为默认格式。我的同事在 linux 或 mac 机器上生成的所有脚本都可以正常工作，但是我会在 windows 中编辑它们，直到我尝试在 linux 机器上运行一个脚本之前，我都没有想到可能会出现问题。

首先，这可以在 cygwin 或 bash 中通过以下方式诊断：

cat -v file.py

如果是 DOS 格式，每行的末尾都会有一个 ^M

其次，cygwin 有一个简单的转换器：

d2u file.py

然后您可以检查它是否像第一步一样工作。然后我的所有脚本都会照常运行。

【讨论】：

【解决方案2】：

谜团在于为什么您无需转换即可运行它。由于您的 shebang 告诉 env 执行不存在的 python^M，因此所有其他行为都是预期的。 或者是吗？ 如果您的$PATH 中有一个名为python^M 的符号链接或脚本（但在其他用户中没有），则可以解释这种奇怪的行为。执行type -a python^M（按Ctrl-V，然后按Ctrl-M 生成^M）。

如果您将 shebang 更改为 #!/usr/bin/python，应该会有所不同。你应该得到-bash: ./script.py: /usr/bin/python^M: bad interpreter: No such file or directory 而不是: No such file or directory。

【讨论】：

您提供了我需要破解此问题的线索 - 我主要担心的是为什么我没有为其他用户获得相同的行为。事实证明，问题出在 git 配置上——脚本来自 git 存储库。新用户从他们的 Cygwin 安装中复制了他们的 .gitconfig，其中恰好包含 core.autocrlf=true - 这将存储库中的所有脚本转换为 DOS 格式。这就是用户之间存在差异的原因。

【解决方案3】：

我已经解决了这个问题，为了完整起见，我将自己回答。

问题源于我们在 Cygwin/Windows 上使用 git，core.autocrlf=true。我们这样做是出于各种原因，而且改变并非易事。

登录 Linux 机器的原始新用户也将包含 core.autocrlf=true 的 Cygwin .gitconfig 复制到他们的新帐户。然后他们克隆了包含相关 python 脚本的 git 存储库。我没有在原始问题中包含此信息，因为我根本没有建立联系。我不想通过解释看似无关的事情来混淆这个问题。事后诸葛亮？

无论如何，这使得所有脚本都以 DOS 格式克隆，这就解释了为什么该用户无法正常工作。它还解释了为什么错误消息没有用，因为 ^M 回车符将光标返回到行首而没有换行，然后“没有这样的文件或目录”覆盖了消息的有用部分.当我将 PATH 设置为没有权限的目录时，我发现了这一点，并收到了损坏的消息“权限被拒绝” - 那个流氓'n'让我思考。

所以我最初假设我们都在运行同一个脚本（因为它们都来自同一个 git 存储库）是错误的——我们实际上根本没有运行同一个脚本。对于我们大多数人来说，它是一个 UNIX 格式的 Python 脚本，但对于这个用户来说，它是 DOS 格式的。最终结果是一个非常简单的问题，但我们再次被与 Windows 相关的问题所困扰。不会是最后一次。

感谢大家的回复。

【讨论】：