“没有这样的文件或目录”但它存在

发布于 2024-09-27 14:03:05 字数 481 浏览 4 评论 0原文

我只想从命令行运行可执行文件 ./arm-mingw32ce-g++,但随后我收到错误消息,

bash: ./arm-mingw32ce-g++: No such file or directory

我正在运行 Ubuntu Linux 10.10。 ls -l 列出

-rwxr-xr-x 1 root root  433308 2010-10-16 21:32 arm-mingw32ce-g++

使用 sudo (sudo ./arm-mingw32ce-g++) 让

sudo: unable to execute ./arm-mingw32ce-g++: No such file or directory

我不知道为什么操作系统甚至看不到该文件。有什么想法吗?

I simply want to run an executable from the command line, ./arm-mingw32ce-g++, but then I get the error message,

bash: ./arm-mingw32ce-g++: No such file or directory

I'm running Ubuntu Linux 10.10. ls -l lists

-rwxr-xr-x 1 root root  433308 2010-10-16 21:32 arm-mingw32ce-g++

Using sudo (sudo ./arm-mingw32ce-g++) gives

sudo: unable to execute ./arm-mingw32ce-g++: No such file or directory

I have no idea why the OS can't even see the file when it's there. Any thoughts?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(21

九局 2024-10-04 14:03:06

正如其他人提到的,这是因为找不到加载程序,而不是您的可执行文件。不幸的是,消息还不够明确。

您可以通过更改可执行文件使用的加载程序来修复它,请参阅我在另一个问题中的完整答案:单个主机上的多个 glibc 库

基本上,您必须找到它尝试使用的加载程序:

$ readelf -l arm-mingw32ce-g++ | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]

然后找到等效加载程序的正确路径,并更改您的可执行文件以使用来自的加载程序它真正的路径:

$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g++

您可能还需要设置包含的路径,在尝试运行它后您就会知道是否需要它。请参阅其他线程中的所有详细信息。

As mentioned by others, this is because the loader can't be found, not your executable file. Unfortunately the message is not clear enough.

You can fix it by changing the loader that your executable uses, see my thorough answer in this other question: Multiple glibc libraries on a single host

Basically you have to find which loader it's trying to use:

$ readelf -l arm-mingw32ce-g++ | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]

Then find the right path for an equivalent loader, and change your executable to use the loader from the path that it really is:

$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g++

You will probably need to set the path of the includes too, you will know if you want it or not after you try to run it. See all the details in that other thread.

余生再见 2024-10-04 14:03:06

我收到此错误“没有这样的文件或目录”,但它存在,因为我的文件是在 Windows 中创建的,我尝试在 Ubuntu 上运行它,并且该文件包含无效的 15\r(其中包含新行)那里。
我刚刚创建了一个新文件,截断了不需要的内容

sleep: invalid time interval ‘15\r’
Try 'sleep --help' for more information.
script.sh: 5: script.sh: /opt/ag/cont: not found
script.sh: 6: script.sh: /opt/ag/cont: not found
root@Ubuntu14:/home/abc12/Desktop# vi script.sh 
root@Ubuntu14:/home/abc12/Desktop# od -c script.sh 
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v       b
0000020   a   s   h  \r  \n   w   g   e   t       h   t   t   p   :   /

0000400   :   4   1   2   0   /  \r  \n
0000410
root@Ubuntu14:/home/abc12/Desktop# tr -d \\015 < script.sh > script.sh.fixed
root@Ubuntu14:/home/abc12/Desktop# od -c script.sh.fixed 
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v       b
0000020   a   s   h  \n   w   g   e   t       h   t   t   p   :   /   /

0000400   /  \n
0000402
root@Ubuntu14:/home/abc12/Desktop# sh -x script.sh.fixed 

I got this error “No such file or directory” but it exists because my file was created in Windows and I tried to run it on Ubuntu and the file contained invalid 15\r where ever a new line was there.
I just created a new file truncating unwanted stuff

sleep: invalid time interval ‘15\r’
Try 'sleep --help' for more information.
script.sh: 5: script.sh: /opt/ag/cont: not found
script.sh: 6: script.sh: /opt/ag/cont: not found
root@Ubuntu14:/home/abc12/Desktop# vi script.sh 
root@Ubuntu14:/home/abc12/Desktop# od -c script.sh 
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v       b
0000020   a   s   h  \r  \n   w   g   e   t       h   t   t   p   :   /

0000400   :   4   1   2   0   /  \r  \n
0000410
root@Ubuntu14:/home/abc12/Desktop# tr -d \\015 < script.sh > script.sh.fixed
root@Ubuntu14:/home/abc12/Desktop# od -c script.sh.fixed 
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v       b
0000020   a   s   h  \n   w   g   e   t       h   t   t   p   :   /   /

0000400   /  \n
0000402
root@Ubuntu14:/home/abc12/Desktop# sh -x script.sh.fixed 
为你拒绝所有暧昧 2024-10-04 14:03:06

添加到此处以供将来参考(供可能遇到相同情况的用户使用):
当在 Windows 上工作(由于行分隔符与 Linux 系统不同,它引入了额外的字符)并尝试在 Linux 中运行此脚本(插入了额外的字符)时,会发生此错误。该错误消息具有误导性。

在 Windows 中,行分隔符是 CRLF (\r\n),而在 Linux 中是 LF (\n)。这通常可以在文本编辑器中选择。

就我而言,这是由于在 Windows 上工作并上传到 Unix 服务器执行而发生的。

Added here for future reference (for users who might fall into the same case):
This error happens when working on Windows (which introduces extra characters because of different line separator than Linux system) and trying to run this script (with extra characters inserted) in Linux. The error message is misleading.

In Windows, the line separator is CRLF (\r\n) whereas in linux it is LF (\n). This can be usually be chosen in text editor.

In my case, this happened due to working on Windows and uploading to Unix server for execution.

左岸枫 2024-10-04 14:03:06

对于不存在 32/64 位问题的简单 bash 脚本,我遇到了相同的错误。这可能是因为您尝试运行的脚本中有错误。此 ubuntu 论坛帖子 表明使用普通脚本文件,您可以在前面添加 sh ,您可能会从中得到一些调试输出。例如

$ sudo sh arm-mingw32ce-g++

,看看你是否得到任何输出。

就我而言,实际问题是我尝试执行的文件是 Windows 格式而不是 Linux 格式。

I got the same error for a simple bash script that wouldn't have 32/64-bit issues. This is possibly because the script you are trying to run has an error in it. This ubuntu forum post indicates that with normal script files you can add sh in front and you might get some debug output from it. e.g.

$ sudo sh arm-mingw32ce-g++

and see if you get any output.

In my case the actual problem was that the file that I was trying to execute was in Windows format rather than Linux.

骄兵必败 2024-10-04 14:03:06

我在 Mac 上创建的文件也遇到了同样的问题。
如果我尝试在 shell 中使用 ./filename 运行它,我会收到文件未找到错误消息。
我认为该文件有问题。

我所做的:

打开到服务器的 ssh 会话
cat 文件名
将输出复制到剪贴板
rm 文件名
触摸文件名
vi 文件名
i 表示插入模式
粘贴剪贴板中的内容
ESC 结束插入模式
:wq!

这对我有用。

I had the same problem with a file that I've created on my mac.
If I try to run it in a shell with ./filename I got the file not found error message.
I think that something was wrong with the file.

what I've done:

open a ssh session to the server
cat filename
copy the output to the clipboard
rm filename
touch filename
vi filename
i for insert mode
paste the content from the clipboard
ESC to end insert mode
:wq!

This worked for me.

动次打次papapa 2024-10-04 14:03:06

以下命令适用于 16.4 Ubuntu

当您的 .sh 文件损坏或未按照 Unix 协议进行格式化时,就会出现此问题。

dos2unix 将.sh 文件转换为Unix 格式!

sudo apt-get install dos2unix -y
dos2unix test.sh
sudo chmod u+x test.sh 
sudo ./test.sh

Below command worked on 16.4 Ubuntu

This issue comes when your .sh file is corrupt or not formatted as per unix protocols.

dos2unix converts the .sh file to Unix format!

sudo apt-get install dos2unix -y
dos2unix test.sh
sudo chmod u+x test.sh 
sudo ./test.sh
少女七分熟 2024-10-04 14:03:06

.sh 脚本中,每行必须以单个字符结尾 - 换行符(LF 或“ >\n”)。

不要像我一样犯错误,因为我选择的文本编辑器是 Win 中的 Notepad++。
以Win结尾的默认行是“\r\n”(CR LF),这样的结尾是不是 Linux shell 脚本的标准。

In a .sh script, each line MUST end with a single character - newline (LF or "\n").

Don't make mistakes like me, because my text-editor of choice is Notepad++ in Win.
The default line ending in Win is "\r\n" (CR LF), and such ending is not standard for Linux shell scripts.

◇流星雨 2024-10-04 14:03:06

这个:sed -i -e 's/\r$//' FILE可能会解决您的问题。

正如许多答案已经解释的那样,此问题可能是由 Windows 中的行结尾为 \r\n 引起的,而 Linux 中的行结尾仅为 \n 造成的。建议的方法是使用 dos2unix。据我所知,这在大多数 Linux 发行版上并不是标准的,就我而言,我无法安装/使用它。

因此我使用了以下方法,(在 Bash 脚本 - “/bin/bash^M:错误的解释器:没有这样的文件或目录”),您可以在其中使用 sed 命令。

sed -i -e 's/\r$//' FILE 其中将 FILE 替换为文件名,例如 sed -i -e ' s/\r$//' myscript.sh

如果您由于某种原因没有安装 sed 但又不想使用 dos2unix 您可以使用按照以下步骤安装 sed

sudo apt-get update
sudo apt-get install sed

This: sed -i -e 's/\r$//' FILE, could potentially fix your problem.

As many answers already have explained, this issue could be caused by line endings being \r\n in Windows and only \n in Linux. A suggested approach was to use dos2unix. As far as I understand this is not standard on most Linux distributions, and in my case I could not install / use it.

Therefore I used the following approach, (mentioned in Bash script – "/bin/bash^M: bad interpreter: No such file or directory"), where you can use the sed command instead.

sed -i -e 's/\r$//' FILE where you replace FILE with the name of your file, e.g. sed -i -e 's/\r$//' myscript.sh

If you for some reason do not have sed installed but do not want to use dos2unix you can use the following to install sed:

sudo apt-get update
sudo apt-get install sed
甜尕妞 2024-10-04 14:03:06

我刚刚在 mingw32 bash 中遇到了这个问题。我从 Program Files (x86)\nodejs 执行了 node/npm,然后将它们移到 disabled 目录中(本质上是从路径中删除它们)。我的路径中还有 Program Files\nodejs (即 64 位版本),但仅在 x86 版本之后。重新启动bash shell后,可以找到64位版本的npm。 node 始终正常工作(使用 node -v 检查,当 x86 版本移动时,它发生了变化)。

我认为 bash -r 会起作用,而不是重新启动 bash: https://unix.stackexchange.com /a/5610

I just had this issue in mingw32 bash. I had execuded node/npm from Program Files (x86)\nodejs and then moved them into disabled directory (essentially removing them from path). I also had Program Files\nodejs (ie. 64bit version) in path, but only after the x86 version. After restarting the bash shell, the 64bit version of npm could be found. node worked correctly all the time (checked with node -v that changed when x86 version was moved).

I think bash -r would've worked instead of restarting bash: https://unix.stackexchange.com/a/5610

醉城メ夜风 2024-10-04 14:03:06

我遇到了这个问题,原因是某些编辑器(例如 Notepad++)已停产。您可以在编辑菜单/EOL 转换中检查它。应选择 Unix(LF)。
我希望它会有用。

I had this issue and the reason was EOL in some editors such as Notepad++. You can check it in Edit menu/EOL conversion. Unix(LF) should be selected.
I hope it would be useful.

流星番茄 2024-10-04 14:03:06

尝试运行 terraform/terragrunt (单向二进制)时遇到此错误。

使用 which terragrunt 查找可执行文件的位置,在本地目录或使用完整路径运行它时出现奇怪的错误

bash: ./terragrunt: No such file or directory

问题是有两个 terragrunt 安装,使用 brew uninstall terragrunt删除一个固定它。

删除后,which terragrunt 显示了新路径 /usr/bin/terragrunt 一切正常。

Hit this error trying to run terraform/terragrunt (Single go binary).

Using which terragrunt to find where executable was, got strange error when running it in local dir or with full path

bash: ./terragrunt: No such file or directory

Problem was that there was two installations of terragrunt, used brew uninstall terragrunt to remove one fixed it.

After removing the one, which terragrunt showed the new path /usr/bin/terragrunt everything worked fine.

我的痛♀有谁懂 2024-10-04 14:03:06

对于那些在运行 java 程序时遇到此错误的人,可能是您尝试在 32 位 Linux 操作系统上运行 64 位 java 程序。

当我在 64 位 java 上运行 ldd 时我才意识到其中报告:

ldd /usr/java/jdk1.8.0_05/bin/java

'不是动态可执行文件'

而旧的 32 位 java 报告了合理的结果:

ldd /usr/java/jdk1.8.0_05/bin/java

For those encountering this error when running a java program, it's possible that you're trying to run a 64-bit java program using on a 32-bit linux operating system.

I only realised when I ran ldd on 64-bit java which reported:

ldd /usr/java/jdk1.8.0_05/bin/java

'not a dynamic executable'

Whereas the old 32 bit java reported sensible results:

ldd /usr/java/jdk1.8.0_05/bin/java

弥繁 2024-10-04 14:03:06

就我而言,事实证明该文件是一个符号链接:

$ cat deluge-gtk.lock
cat: deluge-gtk.lock: No such file or directory
$ file deluge-gtk.lock
deluge-gtk.lock: broken symbolic link to 32309

像这样的误导性错误在 Linux 上相当常见。相关讨论:https://lwn.net/Articles/532771/

In my case, it turns out the file was a symlink:

$ cat deluge-gtk.lock
cat: deluge-gtk.lock: No such file or directory
$ file deluge-gtk.lock
deluge-gtk.lock: broken symbolic link to 32309

Misleading errors like this are fairly common on Linux. Related discussion: https://lwn.net/Articles/532771/

流殇 2024-10-04 14:03:06

对于未来的读者,我在尝试使用 Gunicorn 启动 Django 服务器时遇到了这个问题。我使用 AWS CodeBuild 构建虚拟环境并运行测试,并使用 CodeDeploy 将构建的工件放到生产服务器上并启动新版本(所有环境都是 Ubuntu 20.04)。我错误地认为 env/bin/... 包含本机库的实际二进制文件,但事实并非如此。它只是 Python 脚本,带有构建机器上 Python 解释器的路径。就我而言,安装软件包和实际运行软件包的机器是不同的。更具体地说,env/bin 中的所有文件都有 shebang #!/codebuild/output/src715682316/src/env/bin/python,所以当然在生产服务器上运行 env/bin/gunicorn 将会失败。神秘的错误消息是 Ubuntu 告诉我 env/bin/gunicorn 不存在,而不是说 /codebuild/output/src715682316/src/env/bin/python代码> 不存在。我能够通过使用 python3 env/bin/gunicorn 而不是 env/bin/gunicorn 启动 Gunicorn 来解决此问题。

For future readers, I had this issue when trying to launch a Django server using gunicorn. I was using AWS CodeBuild to build the virtual environment and run tests and using CodeDeploy to put the built artifacts onto the production server and launch the new version (all environments were Ubuntu 20.04). I had mistakenly thought that env/bin/... contained actual binaries of native libraries but that was not the case. It was just Python scripts with a shebang of the path to the Python interpreter on the build machine. In my case, the machine installing the packages and actually running the packages was different. To be more specific, all of the files in env/bin had the shebang #!/codebuild/output/src715682316/src/env/bin/python, so of course running env/bin/gunicorn on the production server would fail. The cryptic error message was when Ubuntu would tell me that env/bin/gunicorn didn't exist as opposed to saying /codebuild/output/src715682316/src/env/bin/python didn't exist. I was able to fix this problem by starting gunicorn using python3 env/bin/gunicorn instead of env/bin/gunicorn.

鸢与 2024-10-04 14:03:06

另一个可能的原因:该文件是一个动态链接到

debian 系统上的 musl (最有可能是 alpine)的二进制文件,您必须安装

apt-get update -y && apt-get install -y musl musl-dev musl-tools

Yet another possible reason: the file is a binary linked dynamically against musl (most likely for alpine)

on debian system you will have to install

apt-get update -y && apt-get install -y musl musl-dev musl-tools
合久必婚 2024-10-04 14:03:06

不是同样的问题,但可能对某些人有帮助

我的脚本:

#!/bin/sh

calm-cat="$HOME/blabla"
echo $calm-cat

我的主目录中有 blabla,但

错误消息:./b.sh:第 3 行:calm-cat=/home/bob/blabla:否这样的文件或目录

是因为shell脚本变量名不能包含破折号(-)

所以将其更改为calm_cat将解决该问题

not the same problem, but maybe helpful for some people

my script:

#!/bin/sh

calm-cat="$HOME/blabla"
echo $calm-cat

i have blabla in my home directory, but

error message: ./b.sh: line 3: calm-cat=/home/bob/blabla: No such file or directory

it's because shell script variable name can't contain dash (-)

so change it to calm_cat will solve that problem

在梵高的星空下 2024-10-04 14:03:05

此错误可能意味着 ./arm-mingw32ce-g++ 不存在(但确实存在),或者它存在并且是内核识别的动态链接可执行文件,但其动态加载器不可用。运行ldd /arm-mingw32ce-g++就可以看到需要什么动态加载器;任何标记为“未找到”的内容都是您需要安装的动态加载程序或库。

如果您尝试在 amd64 安装上运行 32 位二进制文​​件:

This error can mean that ./arm-mingw32ce-g++ doesn't exist (but it does), or that it exists and is a dynamically linked executable recognized by the kernel but whose dynamic loader is not available. You can see what dynamic loader is required by running ldd /arm-mingw32ce-g++; anything marked not found is the dynamic loader or a library that you need to install.

If you're trying to run a 32-bit binary on an amd64 installation:

软的没边 2024-10-04 14:03:05

当我尝试在 Ubuntu 上构建 Selenium 源代码时,我遇到了这个错误。即使我满足了所有先决条件,具有正确 shebang 的简单 shell 脚本也无法运行。

file file-name # helped me in understanding that CRLF ending were present in the file.

我在 Vim 中打开这个文件,我可以看到,因为我曾经在 Windows 机器上编辑过这个文件,所以它是 DOS 格式的。我使用以下命令将文件转换为 Unix 格式:

dos2unix filename # actually helped me and things were fine.

我希望我们在跨平台编辑文件时应该小心,我们也应该注意文件格式。

I faced this error when I was trying to build Selenium source on Ubuntu. The simple shell script with correct shebang was not able to run even after I had all pre-requisites covered.

file file-name # helped me in understanding that CRLF ending were present in the file.

I opened the file in Vim and I could see that just because I once edited this file on a Windows machine, it was in DOS format. I converted the file to Unix format with below command:

dos2unix filename # actually helped me and things were fine.

I hope that we should take care whenever we edit files across platforms we should take care for the file formats as well.

从来不烧饼 2024-10-04 14:03:05

如果尝试运行脚本并且 shebang 拼写错误,也可能会出现此错误。确保它读取 #!/bin/sh#!/bin/bash 或您使用的任何解释器。

This error may also occur if trying to run a script and the shebang is misspelled. Make sure it reads #!/bin/sh, #!/bin/bash, or whichever interpreter you're using.

尐籹人 2024-10-04 14:03:05

当我尝试运行 Python 脚本时,我遇到了同样的错误消息——这不是 @Warpspace 的预期用例(请参阅其他评论),但这是我搜索的热门搜索之一,所以也许有人会发现它有用。

就我而言,shebang 行 (#!/usr/bin/env python)会被绊倒。一个简单的 dos2unix myfile.py 修复了它。

I had the same error message when trying to run a Python script -- this was not @Warpspace's intended use case (see other comments), but this was among the top hits to my search, so maybe somebody will find it useful.

In my case it was the DOS line endings (\r\n instead of \n) that the shebang line (#!/usr/bin/env python) would trip over. A simple dos2unix myfile.py fixed it.

屌丝范 2024-10-04 14:03:05

我在此处找到了适用于 Ubuntu 18 的解决方案。

sudo dpkg --add-architecture i386

然后:

sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

I found my solution for my Ubuntu 18 here.

sudo dpkg --add-architecture i386

Then:

sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文