Aucun fichier ou répertoire de ce type ? Mais le fichier existe !

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 que vous 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 dans linux c'est LF ( \n ). Dans mon cas, cela s'est produit parce que je travaillais sous Windows et que je téléchargeais sur un serveur Unix pour l'exécution.

Google m'a conduit à cette page. Mon problème n'avait qu'un lointain rapport avec le titre de ce fil de discussion, c'est pourquoi je le publie ici pour les futurs visiteurs comme moi :

C'est l'un des problèmes les plus étranges :

$ ls -lh
ls: cannot access .~dataprep.ipynb: No such file or directory
-????????? ? ?      ?           ?            ? .~dataprep.ipynb
-rw------- 1 tgowda mygroup 475K Jun 12 15:59 dataprep.ipynb

Je vois que le fichier .~dataprep.ipynb est juste là avec quelques bizarreries ?? les permissions. Je voulais juste me débarrasser de ce fichier en désordre. rm n'a pas pu le supprimer. mv Le commandement ne pouvait pas le déplacer.

Et puis...

$ python
>>> from pathlib import Path
>>> list(Path('.').glob("*.ipynb"))
[PosixPath('.~dataprep.ipynb'), PosixPath('dataprep.ipynb')]
>>> p = list(Path('.').glob("*.ipynb"))[0]
>>> p
PosixPath('.~dataprep.ipynb')
>>> p.unlink()
>>> list(Path('.').glob("*.ipynb"))
[PosixPath('dataprep.ipynb')]

Et c'est comme ça que j'ai pu le vaincre.

Comme indiqué dans https://askubuntu.com/a/1035037/676490

sudo apt-get install lsb

a résolu le problème

Aucune des réponses ci-dessus n'a fonctionné pour moi car il y avait une erreur de résolution pour l'interprète.

J'ai écrit un réponse détaillée ici qui explique comment résoudre ce problème.

Merci à cet homme qui a partagé son expérience avec d'autres. solution ici . Grâce à lui, j'ai pu résoudre ce problème.

Pour résumer, comme @steeldriver l'a dit, il y avait un problème d'interpréteur. Le linker donne à mon programme [/lib/ld64.so.1] comme interpréteur ELF mais ce chemin n'existe pas du tout et je l'ai vérifié :

> ls /lib/ld64.so.1
ls: cannot access '/lib/ld64.so.1': No such file or directory

Après cela, j'ai vérifié les chemins des interprètes sur mon installation ubuntu :

> ls /lib64/ld-*
/lib64/ld-linux-x86-64.so.2  /lib64/ld-lsb-x86-64.so.2  /lib64/ld-lsb-x86-64.so.3

La solution est donc de créer un lien d'un de ces interprètes vers le chemin de l'interprète inexistant par :

sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1

Maintenant nous revérifions l'interprète inexistant une fois de plus pour voir s'il est toujours inexistant ou non :

> ls /lib/ld64.so.1
/lib/ld64.so.1

Maintenant, cette commande a retourné /lib/ld64.so.1 au lieu de "fichier inexistant". Le problème a donc été résolu et j'ai pu exécuter ./main avec succès.

Donc, en résumé, vous devez créer un lien d'un de ces interprètes vers le chemin de l'interprète inexistant en exécutant la commande suivante dans un terminal ( Ctrl + Alt + T ) :

sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1