"Keine solche Datei oder Verzeichnis", aber es existiert

Ich möchte einfach eine ausführbare Datei über die Befehlszeile ausführen ./arm-mingw32ce-g++, erhalte dann aber die Fehlermeldung:

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

Ich verwende Ubuntu Linux 10.10. ls -lListen

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

Mit sudo ( sudo ./arm-mingw32ce-g++) gibt

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

Ich habe keine Ahnung, warum das Betriebssystem die Datei nicht einmal sehen kann, wenn sie dort ist. Irgendwelche Gedanken?

Dieser Fehler kann bedeuten, dass er ./arm-mingw32ce-g++nicht existiert (aber existiert) oder dass er existiert und eine dynamisch verknüpfte ausführbare Datei ist, die vom Kernel erkannt wird, deren dynamischer Loader jedoch nicht verfügbar ist. Sie können sehen, welcher dynamische Lader erforderlich ist, indem Sie ausführen ldd /arm-mingw32ce-g++. alles markiertnot found ist, ist der dynamische Lader oder eine Bibliothek, die Sie installieren müssen.

Wenn Sie versuchen, eine 32-Bit-Binärdatei auf einer amd64-Installation auszuführen:

• Installieren Sie das Paket bis Ubuntu 11.04 ia32-libs.
• Installieren Sie unter Ubuntu 11.10 ia32-libs-multiarch.
• Installieren ia32-libs-multiarchoder wählen Sie ab 12.04 :i386zusätzlich zu den :amd64Paketen einen angemessenen Satz von Paketen aus.

Ich hatte diesen Fehler, als ich versuchte, eine Selenium-Quelle unter Ubuntu zu erstellen. Das einfache Shell-Skript mit korrektem Shebang konnte nicht ausgeführt werden, selbst nachdem alle Voraussetzungen abgedeckt waren.

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

Ich habe die Datei in Vim geöffnet und konnte sehen, dass diese Datei, nur nachdem ich sie einmal auf einem Windows-Computer bearbeitet hatte, im DOS-Format war. Ich habe die Datei mit dem folgenden Befehl in das Unix-Format konvertiert:

dos2unix filename # actually helped me and things were fine.

Ich hoffe, dass wir uns bei der plattformübergreifenden Bearbeitung von Dateien auch um die Dateiformate kümmern sollten.

Dieser Fehler kann auch auftreten, wenn versucht wird, ein Skript auszuführen, und der Shebang falsch geschrieben ist. Stellen Sie sicher #!/bin/sh, dass es liest #!/bin/bashoder welchen Interpreter Sie verwenden.

Ich hatte die gleiche Fehlermeldung beim Versuch, ein Python-Skript auszuführen - dies war nicht der beabsichtigte Anwendungsfall von @ Warpspace (siehe andere Kommentare), aber dies war einer der Top-Treffer meiner Suche, sodass es vielleicht jemand nützlich finden wird.

In meinem Fall waren es die DOS-Zeilenenden ( \r\nanstelle von \n), über die die Shebang-Zeile ( #!/usr/bin/env python) stolpern würde. Eine einfache dos2unix myfile.pyLösung.

Ich habe den gleichen Fehler für ein einfaches Bash-Skript erhalten, das keine 32/64-Bit-Probleme hätte. Dies liegt möglicherweise daran, dass das Skript, das Sie ausführen möchten, einen Fehler enthält. Dieser Ubuntu-Forumsbeitrag weist darauf hin, dass Sie mit normalen Skriptdateien 'sh' vorne hinzufügen können und möglicherweise eine Debug-Ausgabe erhalten. z.B

$ sudo sh arm-mingw32ce-g++

und sehen Sie, ob Sie eine Ausgabe erhalten.

In meinem Fall bestand das eigentliche Problem darin, dass die Datei, die ich ausführen wollte, im Windows-Format und nicht unter Linux war.

Ich habe diesen Fehler erhalten, “No such file or directory”aber er existiert, weil meine Datei unter Windows erstellt wurde und ich versucht habe, sie unter Ubuntu auszuführen. Die Datei enthielt ungültige 15 \ r, wo immer eine neue Zeile vorhanden war. Ich habe gerade eine neue Datei erstellt, in der unerwünschte Inhalte abgeschnitten werden

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 

Der folgende Befehl funktionierte unter 16.4 Ubuntu

Dieses Problem tritt auf, wenn Ihre .sh-Datei beschädigt oder nicht gemäß Unix-Protokollen formatiert ist.

dos2unix konvertiert die .sh-Datei in das Unix-Format!

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

Ich hatte das gleiche Problem mit einer Datei, die ich auf meinem Mac erstellt habe. Wenn ich versuche, es in einer Shell mit ./Dateiname auszuführen, wird die Fehlermeldung Datei nicht gefunden angezeigt. Ich denke, dass etwas mit der Datei nicht stimmte.

was ich getan habe:

Öffnen Sie eine SSH - Sitzung an den Server
cat Dateinamen
kopieren Sie die Ausgabe in die Zwischenablage
rm Dateiname
Touch Dateiname
vi Dateiname
i für Insert - Modus
den Inhalt aus der Zwischenablage einfügen
ESC Endeinsatzes Modus
: wq!

Das hat bei mir funktioniert.

Ich hatte gerade dieses Problem in mingw32 bash. Ich hatte node / npm von ausgeführt Program Files (x86)\nodejsund sie dann in ein disabledVerzeichnis verschoben (im Wesentlichen aus dem Pfad entfernt). Ich hatte auch Program Files\nodejs(dh 64-Bit-Version) im Pfad, aber erst nach der x86-Version. Nach dem Neustart der Bash-Shell konnte die 64-Bit-Version von npm gefunden werden. nodefunktionierte die ganze Zeit korrekt (überprüft, node -vdass dies geändert wurde, als die x86-Version verschoben wurde).

Ich denke, es bash -rhätte funktioniert, anstatt bash neu zu starten: https://unix.stackexchange.com/a/5610

Wie von anderen erwähnt, liegt dies daran, dass der Loader nicht gefunden werden kann, nicht Ihre ausführbare Datei. Leider ist die Nachricht nicht klar genug.

Sie können das Problem beheben, indem Sie den von Ihrer ausführbaren Datei verwendeten Loader ändern. Meine ausführliche Antwort finden Sie in dieser anderen Frage: Mehrere glibc-Bibliotheken auf einem einzelnen Host

Grundsätzlich müssen Sie herausfinden, welchen Loader er verwenden möchte:

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

Suchen Sie dann den richtigen Pfad für einen äquivalenten Loader und ändern Sie Ihre ausführbare Datei so, dass der Loader aus dem Pfad verwendet wird, der er wirklich ist:

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

Sie müssen wahrscheinlich auch den Pfad der Includes festlegen. Sie werden wissen, ob Sie dies möchten oder nicht, nachdem Sie versucht haben, es auszuführen. Alle Details in diesem anderen Thread anzeigen.

Ich habe hier meine Lösung für mein Ubuntu 18 gefunden .

sudo dpkg --add-architecture i386

Dann:

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

Ich hatte dieses Problem und der Grund war EOL in einigen Editoren wie Notepad ++. Sie können dies im Menü Bearbeiten / EOL-Konvertierung überprüfen. Unix (LF) sollte ausgewählt sein. Ich hoffe es wäre nützlich.

Hier hinzugefügt, um später darauf zurückgreifen zu können (für Benutzer, die möglicherweise in denselben Fall fallen): Dieser Fehler tritt auf, wenn Sie unter Windows arbeiten (das zusätzliche Zeichen aufgrund eines anderen Zeilentrennzeichens als das Linux-System einführt) und versuchen, dieses Skript auszuführen (wobei zusätzliche Zeichen eingefügt werden). unter Linux. Die Fehlermeldung ist irreführend.

In Windows ist das Zeilentrennzeichen CRLF ( \ r \ n ), während es unter Linux LF ( \ n ) ist. Dies kann normalerweise im Texteditor gewählt werden.

In meinem Fall geschah dies aufgrund der Arbeit unter Windows und des Hochladens auf den Unix-Server zur Ausführung.