Zo’n bestand of map niet maar het bestaat wel

Ik wil gewoon een uitvoerbaar bestand uitvoeren vanaf de opdrachtregel, ./arm-mingw32ce-g++, maar dan krijg ik de foutmelding,

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

Ik gebruik Ubuntu Linux 10.10. ls -llijsten

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

Het gebruik van sudo (sudo ./arm-mingw32ce-g++) geeft

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

Ik heb geen idee waarom het besturingssysteem het bestand niet eens kan zien als het er is. Enig idee?


Antwoord 1, autoriteit 100%

Deze fout kan betekenen dat ./arm-mingw32ce-g++niet bestaat (maar wel), of dat het bestaat en een dynamisch gekoppeld uitvoerbaar bestand is dat door de kernel wordt herkend, maar waarvan de dynamische lader is niet beschikbaar. U kunt zien welke dynamische lader vereist is door ldd /arm-mingw32ce-g++uit te voeren; alles dat gemarkeerd is als not foundis de dynamische lader of een bibliotheek die je moet installeren.

Als u een 32-bits binair bestand probeert uit te voeren op een amd64-installatie:


Antwoord 2, autoriteit 37%

Ik kwam deze fout tegen toen ik de Selenium-bron op Ubuntu probeerde te bouwen. Het eenvoudige shellscript met de juiste shebang kon niet worden uitgevoerd, zelfs niet nadat ik aan alle vereisten had voldaan.

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

Ik opende het bestand in Vim en ik kon zien dat, alleen omdat ik dit bestand ooit op een Windows-computer had bewerkt, het in DOS-formaat was. Ik heb het bestand geconverteerd naar Unix-formaat met het onderstaande commando:

dos2unix filename # actually helped me and things were fine.

Ik hoop dat we voorzichtig moeten zijn wanneer we bestanden op verschillende platforms bewerken, we moeten ook op de bestandsindelingen letten.


Antwoord 3, autoriteit 24%

Deze fout kan ook optreden als u een script probeert uit te voeren en de shebangis verkeerd gespeld. Zorg ervoor dat er #!/bin/sh, #!/bin/bashstaat, of welke interpreter je ook gebruikt.


Antwoord 4, autoriteit 9%

Ik kreeg dezelfde foutmelding toen ik probeerde een Python-script uit te voeren — dit was niet het beoogde gebruik van @Warpspace (zie andere opmerkingen), maar dit was een van de tophits van mijn zoekopdracht, dus misschien vindt iemand het nuttig .

In mijn geval waren het de DOS-regeluitgangen (\r\nin plaats van \n) die de shebang-regel (#!/usr/bin/env python) zou struikelen. Een simpele dos2unix myfile.pyloste het op.


Antwoord 5, autoriteit 5%

Ik kreeg dezelfde fout voor een eenvoudig bash-script dat geen 32/64-bits problemen zou hebben. Dit is mogelijk omdat het script dat u probeert uit te voeren een fout bevat. Dit ubuntu-forumberichtgeeft aan dat u met normale scriptbestanden kunt voeg shvooraan toe en je zou er wat foutopsporingsoutput van kunnen krijgen. bijv.

$ sudo sh arm-mingw32ce-g++

en kijk of je output krijgt.

In mijn geval was het werkelijke probleem dat het bestand dat ik probeerde uit te voeren in Windows-formaat was in plaats van Linux.


Antwoord 6, autoriteit 3%

Ik kreeg deze fout “No such file or directory”maar het bestaat omdat mijn bestand is gemaakt in Windows en ik heb geprobeerd het op Ubuntu uit te voeren en het bestand bevatte ongeldige 15\r waar ooit een nieuwe lijn was er.
Ik heb zojuist een nieuw bestand gemaakt om ongewenste dingen af ​​te kappen

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
[email protected]:/home/abc12/Desktop# vi script.sh 
[email protected]:/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
[email protected]:/home/abc12/Desktop# tr -d \\015 < script.sh > script.sh.fixed
[email protected]:/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
[email protected]:/home/abc12/Desktop# sh -x script.sh.fixed 

Antwoord 7, autoriteit 3%

Het onderstaande commando werkte op 16.4 Ubuntu

Dit probleem doet zich voor wanneer uw .sh-bestand beschadigd is of niet is geformatteerd volgens de unix-protocollen.

dos2unix converteert het .sh-bestand naar Unix-formaat!

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

Antwoord 8, autoriteit 2%

Ik heb mijn oplossing voor mijn Ubuntu 18 hiergevonden.

sudo dpkg --add-architecture i386

Dan:

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

Antwoord 9

Ik had hetzelfde probleem met een bestand dat ik op mijn Mac heb gemaakt.
Als ik het in een shell probeer uit te voeren met ./bestandsnaam, krijg ik de foutmelding Bestand niet gevonden.
Ik denk dat er iets mis was met het bestand.

wat ik heb gedaan:

open een ssh-sessie naar de server
cat bestandsnaam
kopieer de uitvoer naar het klembord
rm bestandsnaam
raak bestandsnaam
aan
vi bestandsnaam
i voor invoegmodus
plak de inhoud van het klembord
ESC om de invoegmodus te beëindigen
:wq!

Dit werkte voor mij.


Antwoord 10

Ik had dit probleem net in mingw32 bash. Ik had node/npm uit Program Files (x86)\nodejsuitgevoerd en ze vervolgens naar de map disabledverplaatst (waardoor ze in wezen van het pad werden verwijderd). Ik had ook Program Files\nodejs(dwz 64-bits versie) in pad, maar alleen na de x86-versie. Nadat de bash-shell opnieuw was opgestart, kon de 64-bits versie van npm worden gevonden. nodewerkte altijd correct (gecontroleerd met node -vdat veranderde toen de x86-versie werd verplaatst).

Ik denk dat bash -rzou hebben gewerkt in plaats van bash opnieuw te starten: https://unix. stackexchange.com/a/5610


Antwoord 11

Zoals door anderen vermeld, is dit omdat de lader niet kan worden gevonden, niet uw uitvoerbare bestand. Helaas is de boodschap niet duidelijk genoeg.

Je kunt het oplossen door de lader te wijzigen die je uitvoerbare bestand gebruikt, zie mijn uitgebreide antwoord in deze andere vraag: Meerdere glibc-bibliotheken op één host

In principe moet je uitzoeken welke lader het probeert te gebruiken:

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

Zoek vervolgens het juiste pad voor een equivalente lader en wijzig uw uitvoerbare bestand om de lader te gebruiken vanaf het pad dat het werkelijk is:

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

Je zult waarschijnlijk ook het pad van de include moeten instellen, je weet of je het wilt of niet nadat je het probeert uit te voeren. Zie alle details in die andere thread.


Antwoord 12

Ik had dit probleem en de reden was EOL in sommige editors, zoals Notepad++. U kunt dit controleren in het menu Bewerken/EOL-conversie. Unix(LF) moet worden geselecteerd.
Ik hoop dat het nuttig zou zijn.


Antwoord 13

Hier toegevoegd voor toekomstig gebruik (voor gebruikers die mogelijk in hetzelfde geval vallen):
Deze fout treedt op bij het werken aan Windows (dat extra tekens introduceert vanwege een ander regelscheidingsteken dan het Linux-systeem) en probeert dit script uit te voeren (met extra tekens ingevoegd) in Linux. De foutmelding is misleidend.

In Windows is het regelscheidingsteken CRLF (\r\n) terwijl het in Linux LF is (\n). Dit kan meestal worden gekozen in de teksteditor.

In mijn geval gebeurde dit vanwege het werken aan Windows en het uploaden naar de Unix-server voor uitvoering.


Antwoord 14

Kies deze fout bij het uitvoeren van terraform/terragrunt (Single go binary).

Met behulp van which terragruntom te vinden waar het uitvoerbare bestand was, kreeg ik een vreemde fout bij het uitvoeren in de lokale map of met het volledige pad

bash: ./terragrunt: No such file or directory

Het probleem was dat er twee installaties van terragrunt waren, brew uninstall terragruntgebruikten om er één te verwijderen, loste dit op.

Na het verwijderen van die ene, which terragrunthet nieuwe pad /usr/bin/terragruntliet zien, werkte alles prima.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Other episodes