"Aucun fichier ou répertoire de ce type" mais il existe

Je veux simplement exécuter un exécutable à partir de la ligne de commande ./arm-mingw32ce-g++, mais j'obtiens le message d'erreur,

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

J'utilise Ubuntu Linux 10.10. ls -llistes

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

Utiliser sudo ( sudo ./arm-mingw32ce-g++) donne

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

Je ne sais pas pourquoi le système d'exploitation ne peut même pas voir le fichier lorsqu'il est là. Des pensées?

Cette erreur peut signifier que cela ./arm-mingw32ce-g++n'existe pas (mais c'est le cas), ou qu'il existe et qu'il s'agit d'un exécutable lié dynamiquement reconnu par le noyau mais dont le chargeur dynamique n'est pas disponible. Vous pouvez voir quel chargeur dynamique est requis en exécutant ldd /arm-mingw32ce-g++; tout ce qui not foundest marqué est le chargeur dynamique ou une bibliothèque que vous devez installer.

Si vous essayez d'exécuter un binaire 32 bits sur une installation amd64:

• Jusqu'à Ubuntu 11.04, installez le package ia32-libs.
• Sur Ubuntu 11.10, installez ia32-libs-multiarch.
• À partir de 12.04, installez ia32-libs-multiarchou sélectionnez un ensemble raisonnable de :i386packages en plus des :amd64packages.

J'ai rencontré cette erreur lorsque j'essayais de créer une source Selenium sur Ubuntu. Le script shell simple avec shebang correct n'a pas pu s'exécuter même après avoir couvert tous les pré-requis.

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

J'ai ouvert le fichier dans Vim et je pouvais voir que simplement parce que j'avais édité ce fichier sur une machine Windows, il était au format DOS. J'ai converti le fichier au format Unix avec la commande ci-dessous:

dos2unix filename # actually helped me and things were fine.

J'espère que nous devrions faire attention chaque fois que nous éditons des fichiers sur plusieurs plates-formes, nous devrions également prendre soin des formats de fichiers.

Cette erreur peut également se produire si vous essayez d'exécuter un script et que le shebang est mal orthographié. Assurez-vous qu'il lit #!/bin/sh, #!/bin/bashou quel que soit l'interpréteur que vous utilisez.

J'ai eu le même message d'erreur en essayant d'exécuter un script Python - ce n'était pas le cas d'utilisation prévu de @ Warpspace (voir les autres commentaires), mais c'était parmi les meilleurs résultats de ma recherche, alors peut-être que quelqu'un le trouvera utile.

Dans mon cas, c'était les fins de ligne DOS ( \r\nau lieu de \n) sur lesquelles la ligne shebang ( #!/usr/bin/env python) trébucherait. Un simple l'a dos2unix myfile.pycorrigé.

J'ai eu la même erreur pour un simple script bash qui n'aurait pas de problèmes 32/64 bits. C'est peut-être parce que le script que vous essayez d'exécuter contient une erreur. Ce message du forum ubuntu indique qu'avec des fichiers de script normaux, vous pouvez ajouter 'sh' devant et vous pourriez en obtenir une sortie de débogage. par exemple

$ sudo sh arm-mingw32ce-g++

et voyez si vous obtenez une sortie.

Dans mon cas, le problème réel était que le fichier que j'essayais d'exécuter était au format Windows plutôt que Linux.

J'ai eu cette erreur “No such file or directory”mais elle existe car mon fichier a été créé sous Windows et j'ai essayé de l'exécuter sur Ubuntu et le fichier contenait 15 \ r invalide là où une nouvelle ligne était là. Je viens de créer un nouveau fichier tronquant des éléments indésirables

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 

La commande ci-dessous a fonctionné sur 16.4 Ubuntu

Ce problème survient lorsque votre fichier .sh est corrompu ou non formaté selon les protocoles Unix.

dos2unix convertit le fichier .sh au format Unix!

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

J'ai eu le même problème avec un fichier que j'ai créé sur mon mac. Si j'essaye de l'exécuter dans un shell avec ./filename, j'ai le message d'erreur du fichier non trouvé. Je pense que quelque chose n'allait pas avec le fichier.

ce que j'ai fait:

ouvrir une session ssh sur le serveur
cat filename
copiez la sortie dans le presse-papiers
rm filename
touch filename
vi filename
i pour le mode insertion
collez le contenu du presse-papiers
ESC pour terminer le mode insertion
: wq!

Cela a fonctionné pour moi.

Je viens d'avoir ce problème mingw32 bash. J'avais exclu node / npm de Program Files (x86)\nodejspuis les ai déplacés dans le disabledrépertoire (en les supprimant essentiellement du chemin). J'avais aussi Program Files\nodejs(c'est-à-dire la version 64 bits) dans le chemin, mais seulement après la version x86. Après avoir redémarré le shell bash, la version 64 bits de npm a pu être trouvée. nodefonctionnait correctement tout le temps (vérifié avec node -vcela changé lorsque la version x86 a été déplacée).

Je pense que cela bash -raurait fonctionné au lieu de redémarrer bash: https://unix.stackexchange.com/a/5610

Comme mentionné par d'autres, c'est parce que le chargeur est introuvable, pas votre fichier exécutable. Malheureusement, le message n'est pas assez clair.

Vous pouvez le résoudre en changeant le chargeur utilisé par votre exécutable, voir ma réponse approfondie dans cette autre question: plusieurs bibliothèques glibc sur un seul hôte

En gros, vous devez trouver quel chargeur il essaie d'utiliser:

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

Ensuite, trouvez le bon chemin pour un chargeur équivalent, et modifiez votre exécutable pour utiliser le chargeur à partir du chemin qu'il est réellement:

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

Vous devrez probablement également définir le chemin des includes, vous saurez si vous le souhaitez ou non après avoir essayé de l'exécuter. Voir tous les détails dans cet autre fil.

J'ai trouvé ma solution pour mon Ubuntu 18 ici .

sudo dpkg --add-architecture i386

Ensuite:

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

J'ai eu ce problème et la raison était EOL dans certains éditeurs tels que Notepad ++. Vous pouvez le vérifier dans le menu Edition / Conversion EOL. Unix (LF) doit être sélectionné. J'espère que ce serait utile.

Ajouté ici pour référence future (pour les utilisateurs qui pourraient tomber dans le même cas): Cette erreur se produit lorsque vous travaillez sous Windows (qui introduit des caractères supplémentaires en raison d'un séparateur de ligne différent de celui du système Linux) et essayez d'exécuter ce script (avec des caractères supplémentaires insérés) sous Linux. Le message d'erreur est trompeur.

Sous Windows, le séparateur de ligne est CRLF ( \ r \ n ) alors que sous Linux, c'est LF ( \ n ). Cela peut généralement être choisi dans l'éditeur de texte.

Dans mon cas, cela s'est produit en raison du travail sur Windows et du téléchargement sur le serveur Unix pour exécution.