Linux Bash 脚本：错误的解释器
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2841593/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Bash script: bad interpreter
提问by Stefan Steiger
Question: I get this error message:
问题：我收到此错误消息：
export: bad interpreter: No such file or directory
导出：错误的解释器：没有这样的文件或目录
when I execute this bash script:
当我执行这个 bash 脚本时：
#!/bin/bash
MONO_PREFIX=/opt/mono-2.6
GNOME_PREFIX=/opt/gnome-2.6
export DYLD_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
PATH=$MONO_PREFIX/bin:$PATH
PS1="[mono-2.6] \w @ "
But the bash path seems to be correct:
但是 bash 路径似乎是正确的：
asshat@IS1300:~/sources/mono-2.6# which bash
/bin/bash
asshat@IS1300:~# cd sources/
asshat@IS1300:~/sources# cd mono-2.6/
asshat@IS1300:~/sources/mono-2.6# ./mono-2.6-environment
export: bad interpreter: No such file or directory
asshat@IS1300:~/sources/mono-2.6# ls
download mono-2.4 mono-2.4-environment mono-2.6 mono-2.6-environment
asshat@IS1300:~/sources/mono-2.6# cp mono-2.6-environment mono-2.6-environment.sh
asshat@IS1300:~/sources/mono-2.6# ./mono-2.6-environment.sh
export: bad interpreter: No such file or directory
asshat@IS1300:~/sources/mono-2.6# ls
download mono-2.4-environment mono-2.6-environment
mono-2.4 mono-2.6 mono-2.6-environment.sh
asshat@IS1300:~/sources/mono-2.6# bash mono-2.6-environment
asshat@IS1300:~/sources/mono-2.6#
What am I doing wrong? Or is this a Lucid Lynx bug?
我究竟做错了什么？或者这是一个 Lucid Lynx 错误？
I did chmod + x
我做了 chmod + x
采纳答案by Matthias Wandel
The first line, #!/bin/bash, tells Linux where to find the interpreter. The script should also be executable with chmod +x script.sh, which it appears you did.
第一行，#!/bin/bash告诉 Linux 在哪里可以找到解释器。该脚本也应该是可执行的chmod +x script.sh，看起来你做到了。
It is highly likely that you created this file with a windows editor, which will place a <cr><lf>at the end of each line. This is the standard under dos / windows. OS X will place a <cr>at the end of each line. However, under Unix / Linux, the standard is to just put a <lf>at the end of the line.
您很可能使用 Windows 编辑器创建了此文件，该编辑器将<cr><lf>在每行末尾放置一个。这是dos/windows下的标准。OS X 将<cr>在每行的末尾放置一个。但是，在 Unix / Linux 下，标准是<lf>在行尾放置一个。
Linux is now looking for a file called /bin/bash<cr>to interpret the file,
where <cr>is a carriage return character, which is a valid file character under Linux. Such a file doesn't exist. Hence the error.
Linux现在正在寻找一个叫做/bin/bash<cr>解释文件的文件，其中<cr>是回车符，在Linux下是一个有效的文件字符。这样的文件不存在。因此错误。
Solution:Edit the file with an editor on Linux and get rid of the extra <cr>. One tool that usually works when the file is edited on Windows is dos2unix.
解决方案：在 Linux 上使用编辑器编辑文件并去掉多余的<cr>. 在 Windows 上编辑文件时通常可以使用的一种工具是dos2unix.
回答by Anton
Could the script be using Dos newlines?
脚本是否可以使用 Dos 换行符？
Try running dos2unix on it.
尝试在其上运行 dos2unix。
回答by Tim Post
Did you run it like this (you did mention chmod +x)
你是这样运行的吗（你确实提到了 chmod +x）
. /path/to/it
or like this:
或者像这样：
./it
?
?
I have a sneaking suspicion that your code executed in a new process, and everything you told it was lost. Hence, variables will not be expanded in your currentshell. However, this does not explain the bad interpretererror that you saw. I think you also have a terminal problem (as in terminal, what you used to talk to cat).
我偷偷怀疑你的代码在一个新进程中执行，你告诉它的一切都丢失了。因此，变量不会在您当前的shell 中展开。但是，这并不能解释您看到的错误解释器错误。我认为您也有终端问题（如在终端中，您曾经与之交谈的内容cat）。
The fact that your prompt did not do what this said:
您的提示没有执行此操作的事实：
`PS1="[mono-2.6] \w @` "
Makes me think you ran, not sourced the code. There is a difference. I could not get what you posted to break.
让我觉得你跑了，而不是源代码。它们是有区别的。我无法获得您发布的内容。
回答by pol
Had the same problem. Used brute force:
有同样的问题。使用蛮力：
/bin/sh /full/path/to/configure --options
& this did the trick
&这成功了
(Of course I'd like to know why)
（当然我想知道为什么）
回答by jilles
It looks like things have been configured to override the exportbuiltin somehow. This can be done via an exported function or the enablebuiltin, for example. Try putting type exportin the script to check. If you are setting BASH_ENV, you probably shouldn't.
看起来事情已经被配置为export以某种方式覆盖内置。例如，这可以通过导出函数或enable内置函数来完成。尝试放入type export脚本进行检查。如果你正在设置BASH_ENV，你可能不应该。
If bash is called as sh, it enables POSIX mode and does not allow exportto be overridden with a function, as required by POSIX. Likewise, most other shells installed as /bin/shfollow POSIX in this and/or do not allow the execution environment of a script to be messed up so strongly as through importing functions from the environment.
如果 bash 被称为 as sh，它会启用 POSIX 模式，并且不允许export按照 POSIX 的要求被函数覆盖。同样，大多数其他 shell 安装为/bin/sh遵循 POSIX 在这个和/或不允许脚本的执行环境像通过从环境中导入函数那样强烈地搞砸。
By the way, the script seems designed to be sourced, i.e. . ./mono-2.6-environmentinstead of ./mono-2.6-environment.
顺便说一句，该脚本似乎旨在提供源代码，即. ./mono-2.6-environment而不是./mono-2.6-environment.
回答by lathomas64
what worked for me was when dos2Unix wasn't on the system I was working with:
对我有用的是当 dos2Unix 不在我使用的系统上时：
sed -i s/{ctrl+v}{ctrl+m}// filename
回答by gaoithe
This happens sometimes when file system goes funny. Try to move or rename the file. If you see "Stale file handle" error this is your problem.
当文件系统变得有趣时，有时会发生这种情况。尝试移动或重命名文件。如果您看到“陈旧的文件句柄”错误，这就是您的问题。
e.g. happened us with CentOS docker
例如，我们使用 CentOS docker
$ ./test.sh
-bash: ./test.sh: /bin/bash: bad interpreter: Invalid argument
$ ls -alstr test.sh
20 -r-xr-xr-x 0 omen omen 17874 Jun 20 01:36 test.sh
$ cp test.sh testcopy.sh
$ ./testcopy.sh
Happy Days
$ mv test.sh footest.sh
mv: cannot move ‘test.sh' to ‘footest.sh': Stale file handle
$ rm test.sh
rm: cannot remove ‘test.sh': Stale file handle
You can copy the file and read it. But not move it! Nor remove it. Some weird docker file-system thing maybe.
您可以复制文件并阅读它。但不要动它！也不删除。也许是一些奇怪的 docker 文件系统。
Solution:re-create the docker container OR maybe file system repair disk would help
OR of course format c::-D :-o
解决方案：重新创建 docker 容器或者文件系统修复磁盘可能会有所帮助或者当然format c::-D :-o
