在 Ubuntu 中以新用户身份运行脚本时出现 Shell 问题
当我通过 SSH 登录到特定的 Ubuntu Linux（10.04 64 位）主机时，我会得到一个 bash shell。从这里我可以运行一个带有可执行位设置的特定 Python 脚本，该脚本将其作为第一行：
#!/usr/bin/env python
但是，如果另一个（新）用户通过 SSH 登录到同一主机并尝试运行此脚本（或这个）脚本，他们得到这个错误：
$ ./script.py
: No such file or directory
事实证明这个文件实际上是一个 DOS 行结束文件，但我可以从我的登录中运行这个罚款。如果我将它转换为UNIX格式，那么其他人也可以正常运行它。
如果我们在脚本中添加“python”前缀，无论 DOS/UNIX 格式如何，该脚本对我们双方来说都可以正常运行：
$ python ./script.py
blah blah blah...
此外，一旦脚本转换为 UNIX 格式并且其他用户可以运行它，它仍然无法运行a Makefile - make 显示与上面相同的错误。
我读到 /bin/sh 是 Ubuntu 中的“dash”（不是“bash”）shell，我想知道这是否与此有关，因为它的行为与 bash 不同。如果是这样，我想知道我的登录（工作得很好并且已经做了很多年）和这个新用户的登录（显示各种奇怪的行为）之间有什么区别。从哪里开始寻找？
也许也相关 - 新用户是由 Sametime 服务（Active Directory 集成客户端）自动创建的，并且该服务可能以某种方式错误地配置了新用户。
我还尝试将第一行更改为 #!/usr/bin/python ，没有任何区别。
两个用户都运行 bash shell 作为登录 shell。
When I log into a particular Ubuntu Linux (10.04 64bit) host via SSH, I get a bash shell. From here I am able to run a particular Python script, with the executable bit set, that has this as the first line:
#!/usr/bin/env python
However if another (new) user logs into the same host via SSH and tries to run this (or a copy of this) script, they get this error:
$ ./script.py
: No such file or directory
It turns out that this file is actually a DOS line-ending file, yet I can run this fine from my login. If I convert it to UNIX format, then the other person can also run it fine.
The script also runs fine for both of us if we prefix it with 'python', regardless of DOS/UNIX format:
$ python ./script.py
blah blah blah...
Further to this, once the script is converted to UNIX format and the other user can run it, it's still not runnable from a Makefile - make displays the same error as above.
I read that /bin/sh is the 'dash' (not 'bash') shell in Ubuntu and I'm wondering if that has something to do with this, as it behaves differently to bash. If so, I'd like to know what the difference is between my login (which works perfectly fine and has done for years) and this new user's login which is displaying all sorts of weird behaviour. Where to start looking?
Also perhaps relevant - the new user was created automatically by the Likewise service (an Active Directory integration client) and it's possible that this service has configured the new user incorrectly in some way.
I've also tried changing the first line to #!/usr/bin/python with no difference.
Both users are running the bash shell as their login shell.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我遇到了同样的问题，从上面的答案中并不能立即清楚问题是什么，或者解决方案是什么，但我想我现在明白了。
显然，Windows 换行符的编码略有不同。虽然 cygwin 可以以 unix 格式进行编码，但我使用 Windows 文本编辑器 (Notepad++) 来编写脚本，默认格式是 Windows CRLF 编码。 Notepad++ 可以重新配置为unix 默认格式。我的同事在 Linux 或 Mac 机器上生成的所有脚本都可以正常工作，但随后我会在 Windows 中编辑它们，直到我尝试在 Linux 机器上运行脚本时，我才意识到可能会出现问题。
首先，这可以在 cygwin 或 bash 中诊断：
如果是 DOS 格式，则每行末尾都会有一个 ^M
其次，cygwin 有一个简单的转换器：
您可以检查它是否像在第一步。
然后我的所有脚本都会照常运行。
I was having the same issue and it was not immediately clear from the above answers what the problem was, or what the solution was, however I think I now understand.
Apparently windows line breaks are encoded slightly differently. While cygwin can encode in a unix format, I was using a windows text editor (Notepad++) to write my scripts and the default format is windows CRLF encoding. Notepad++ can be reconfigured for unix as the default format. All of the scripts generated by my coworkers on linux or mac machines would work fine, but then I would edit them in windows, and it did not occur to me that there could be a problem until I tried running one on a linux machine.
Firstly, this can be diagnosed in either cygwin or bash with:
where each line will have a ^M at the end if it is in DOS format
Secondly, cygwin has a simple converter:
and you can check to see if that worked as in the first step.
All of my scripts would then run as usual.
神秘的是为什么你能够在没有转换的情况下运行它。所有其他行为都是预期的，因为您的 shebang 告诉
env执行不存在的python^M。 是吗？如果您的$PATH中有一个名为python^M的符号链接或脚本（但在其他用户的路径中没有），那么解释一下这种奇怪的行为。输入 -a python^M（按 Ctrl-V，然后按 Ctrl-M 生成^M）。如果将 shebang 更改为
#!/usr/bin/python，应该会有差异。您应该得到-bash: ./script.py: /usr/bin/python^M: badterpreter: No such file or directory而不是: No such file or directory。The mystery is why you're able to run it without conversion. All the other behavior is expected since your shebang is telling
envto executepython^Mwhich doesn't exist. Or does it? If you have a symlink or script namedpython^Min your$PATH(but not in the other user's) that would explain this odd behavior. Dotype -a python^M(press Ctrl-V then Ctrl-M to produce the^M).If you change the shebang to
#!/usr/bin/pythonthere should be a difference. You should get-bash: ./script.py: /usr/bin/python^M: bad interpreter: No such file or directoryinstead of: No such file or directory.我已经解决了这个问题，并且为了完整起见，我将亲自回答它。
问题源于这样一个事实：我们在 Cygwin/Windows 上使用 git，且 core.autocrlf=true。我们出于各种原因这样做，而且改变并不简单。
登录 Linux 计算机的原始新用户还将包含 core.autocrlf=true 的 Cygwin .gitconfig 复制到他们的新帐户。然后他们克隆了包含相关 python 脚本的 git 存储库。我没有在最初的问题中包含这些信息，因为我根本没有建立联系。我不想通过解释看似无关紧要的事情来混淆问题。事后诸葛亮吧？
无论如何，这使得所有脚本都采用克隆 DOS 格式，这解释了为什么该用户无法正常工作。它还解释了为什么错误消息没有用，因为 ^M 回车符将光标返回到行首而不换行，然后“没有这样的文件或目录”覆盖了消息的有用部分。当我将 PATH 设置为没有权限的目录时，我发现了这一点，并收到损坏的消息“权限被拒绝”——这个流氓“n”让我思考。
所以我最初的假设是我们都运行相同的脚本（因为它们都来自同一个 git 存储库）是错误的 - 我们实际上根本没有运行相同的脚本。对于我们大多数人来说，它是 UNIX 格式的 python 脚本，但对于这个用户来说，它是 DOS 格式的。最后发现这是一个相当简单的问题，但我们再次遇到了与 Windows 相关的问题。不会是最后一次。
感谢大家的回复。
I have solved this and I shall answer it myself for completeness.
The problem stems from the fact that we are using git, on Cygwin/Windows, with core.autocrlf=true. We do this for various reasons and it's non-trivial to change.
The original new user who logged into the Linux machine also copied their Cygwin .gitconfig, which contained core.autocrlf=true, to their new account. Then they cloned the git repository that contained the python script in question. I didn't include this information in the original question because I simply hadn't made the connection. I didn't want to confuse the issue by explaining things that seemed irrelevant. Hindsight eh?
Anyway, this made all the scripts in the clone DOS-format and this explains why nothing would work properly for this user. It also explains why the error messages weren't useful, because the ^M carriage return character was returning the cursor to the start of the line without a linefeed and then the "No such file or directory" was overwriting the useful part of the message. I spotted this when I set the PATH to a directory with no permission, and got the corrupted message "Permission deniedn" - that rogue 'n' got me thinking.
So my initial assumption that we were all running the same script (since they all came from the same git repository) was wrong - we weren't actually running the same script at all. For most of us it was a UNIX-format python script, but for this one user it was DOS-format instead. Turns out to be quite a simple problem in the end, but once again we're bitten by a Windows-related issue. Won't be the last time.
Thanks everyone for your replies.