"Nessun file o directory di questo tipo" ma esiste

Voglio semplicemente eseguire un eseguibile dalla riga di comando ./arm-mingw32ce-g++, ma poi ricevo il messaggio di errore,

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

Sto eseguendo Ubuntu Linux 10.10. ls -lelenchi

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

Usando sudo ( sudo ./arm-mingw32ce-g++) si ottiene

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

Non ho idea del motivo per cui il sistema operativo non può nemmeno vedere il file quando è lì. qualche idea?

Questo errore può significare che ./arm-mingw32ce-g++non esiste (ma esiste), o che esiste ed è un eseguibile collegato dinamicamente riconosciuto dal kernel ma il cui caricatore dinamico non è disponibile. Puoi vedere quale caricatore dinamico è richiesto eseguendo ldd /arm-mingw32ce-g++; tutto ciò che not foundè contrassegnato è il caricatore dinamico o una libreria che devi installare.

Se stai tentando di eseguire un binario a 32 bit su un'installazione amd64:

• Fino a Ubuntu 11.04, installa il pacchetto ia32-libs.
• Su Ubuntu 11.10, installa ia32-libs-multiarch.
• A partire dalla 12.04, installa ia32-libs-multiarcho seleziona un insieme ragionevole di :i386pacchetti oltre ai :amd64pacchetti.

Ho riscontrato questo errore quando stavo cercando di creare il sorgente Selenium su Ubuntu. Il semplice script di shell con lo shebang corretto non è stato in grado di funzionare anche dopo aver coperto tutti i pre-requisiti.

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

Ho aperto il file in Vim e ho potuto vedere che solo perché una volta ho modificato questo file su una macchina Windows, era in formato DOS. Ho convertito il file in formato Unix con il comando seguente:

dos2unix filename # actually helped me and things were fine.

Spero che dovremmo fare attenzione ogni volta che modifichiamo i file su piattaforme diverse dovremmo prenderci cura anche dei formati dei file.

Questo errore può verificarsi anche se si tenta di eseguire uno script e lo shebang è scritto male. Assicurati che legga #!/bin/sh, #!/bin/basho qualunque interprete stai usando.

Ho ricevuto lo stesso messaggio di errore durante il tentativo di eseguire uno script Python: questo non era il caso d'uso previsto da @ Warpspace (vedi altri commenti), ma questo era tra i risultati migliori della mia ricerca, quindi forse qualcuno lo troverà utile.

Nel mio caso erano le terminazioni di riga DOS ( \r\ninvece di \n) su cui inciamperebbe la riga shebang ( #!/usr/bin/env python). Un semplice dos2unix myfile.pyrisolto.

Ho ricevuto lo stesso errore per un semplice script bash che non avrebbe problemi a 32/64 bit. Ciò è possibile perché lo script che stai tentando di eseguire contiene un errore. Questo post sul forum di Ubuntu indica che con i normali file di script è possibile aggiungere "sh" davanti e si potrebbe ottenere un output di debug da esso. per esempio

$ sudo sh arm-mingw32ce-g++

e vedi se ottieni qualche risultato.

Nel mio caso il vero problema era che il file che stavo cercando di eseguire era in formato Windows anziché Linux.

Ho ricevuto questo errore “No such file or directory”ma esiste perché il mio file è stato creato in Windows e ho provato a eseguirlo su Ubuntu e il file conteneva 15 \ r non validi dove c'era una nuova riga. Ho appena creato un nuovo file che tronca le cose indesiderate

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 

Il comando seguente ha funzionato su Ubuntu 16.4

Questo problema si verifica quando il file .sh è danneggiato o non formattato secondo i protocolli unix.

dos2unix converte il file .sh in formato Unix!

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

Ho avuto lo stesso problema con un file che ho creato sul mio Mac. Se provo a eseguirlo in una shell con ./filename ho ricevuto il messaggio di errore file non trovato. Penso che qualcosa non andasse nel file.

quello che ho fatto:

apri una sessione ssh sul server
cat nome file
copia l'output negli appunti
rm nome file
tocca nome file
vi nome file
i per la modalità di inserimento
incolla il contenuto dagli appunti
ESC per terminare la modalità di inserimento
: wq!

Questo ha funzionato per me.

Ho appena avuto questo problema mingw32 bash. Avevo eseguito node / npm da Program Files (x86)\nodejse poi li avevo spostati nella disableddirectory (essenzialmente rimuovendoli dal percorso). Avevo anche Program Files\nodejs(cioè la versione a 64 bit) nel percorso, ma solo dopo la versione x86. Dopo aver riavviato la shell bash, è possibile trovare la versione a 64 bit di npm. nodeha funzionato correttamente tutto il tempo (controllato con node -vquello cambiato quando è stata spostata la versione x86).

Penso che bash -ravrebbe funzionato invece di riavviare bash: https://unix.stackexchange.com/a/5610

Come accennato da altri, questo perché il caricatore non può essere trovato, non il tuo file eseguibile. Purtroppo il messaggio non è abbastanza chiaro.

Puoi risolverlo cambiando il caricatore utilizzato dal tuo eseguibile, vedi la mia risposta completa in quest'altra domanda: più librerie glibc su un singolo host

Fondamentalmente devi trovare quale caricatore sta cercando di utilizzare:

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

Quindi trova il percorso giusto per un caricatore equivalente e modifica il tuo eseguibile per utilizzare il caricatore dal percorso che è realmente:

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

Probabilmente dovrai anche impostare il percorso degli include, saprai se lo vuoi o no dopo aver provato ad eseguirlo. Vedi tutti i dettagli in quell'altro thread.

Ho trovato la mia soluzione per il mio Ubuntu 18 qui .

sudo dpkg --add-architecture i386

Poi:

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

Ho avuto questo problema e il motivo era EOL in alcuni editor come Notepad ++. Puoi controllarlo nel menu Modifica / Conversione EOL. Unix (LF) dovrebbe essere selezionato. Spero possa essere utile.

Aggiunto qui per riferimento futuro (per utenti che potrebbero cadere nello stesso caso): questo errore si verifica quando si lavora su Windows (che introduce caratteri extra a causa del separatore di riga diverso rispetto al sistema Linux) e si tenta di eseguire questo script (con caratteri extra inseriti) in Linux. Il messaggio di errore è fuorviante.

In Windows, il separatore di riga è CRLF ( \ r \ n ) mentre in Linux è LF ( \ n ). Questo di solito può essere scelto nell'editor di testo.

Nel mio caso, ciò è accaduto a causa del lavoro su Windows e del caricamento sul server Unix per l'esecuzione.