„Nie ma takiego pliku lub katalogu”, ale istnieje

Chcę po prostu uruchomić plik wykonywalny z wiersza poleceń ./arm-mingw32ce-g++, ale wtedy pojawia się komunikat o błędzie,

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

Używam Ubuntu Linux 10.10. ls -llisty

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

Użycie sudo ( sudo ./arm-mingw32ce-g++) daje

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

Nie mam pojęcia, dlaczego system operacyjny nie widzi nawet pliku, gdy się tam znajduje. jakieś pomysły?

Ten błąd może oznaczać, że ./arm-mingw32ce-g++nie istnieje (ale istnieje) lub że istnieje i jest dynamicznie połączonym plikiem wykonywalnym rozpoznawanym przez jądro, ale którego dynamiczny moduł ładujący nie jest dostępny. Możesz zobaczyć, jaki dynamiczny moduł ładujący jest wymagany, uruchamiając ldd /arm-mingw32ce-g++; wszystko, co not foundjest zaznaczone, to dynamiczny program ładujący lub biblioteka, którą musisz zainstalować.

Jeśli próbujesz uruchomić 32-bitowy plik binarny na instalacji amd64:

• Do wersji Ubuntu 11.04 zainstaluj pakiet ia32-libs.
• W systemie Ubuntu 11.10 zainstaluj ia32-libs-multiarch.
• Począwszy od 12.04 zainstaluj ia32-libs-multiarchlub wybierz rozsądny zestaw :i386pakietów oprócz :amd64pakietów.

Napotkałem ten błąd, gdy próbowałem zbudować źródło Selenium na Ubuntu. Prosty skrypt powłoki z poprawnym shebang nie mógł działać nawet po spełnieniu wszystkich wymagań wstępnych.

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

Otworzyłem plik w Vimie i zobaczyłem, że tylko dlatego, że kiedyś edytowałem ten plik na komputerze z systemem Windows, był w formacie DOS. Przekonwertowałem plik do formatu Unix za pomocą poniższego polecenia:

dos2unix filename # actually helped me and things were fine.

Mam nadzieję, że powinniśmy uważać za każdym razem, gdy edytujemy pliki na różnych platformach, powinniśmy również zadbać o formaty plików.

Ten błąd może również wystąpić, jeśli próbujesz uruchomić skrypt, a słowo shebang jest błędnie napisane. Upewnij się, że czyta #!/bin/sh, #!/bin/bashlub którykolwiek tłumacz, którego używasz.

Miałem ten sam komunikat o błędzie podczas próby uruchomienia skryptu w Pythonie - nie był to zamierzony przypadek użycia @ Warpspace (zobacz inne komentarze), ale był to jeden z najpopularniejszych wyników wyszukiwania, więc może ktoś uzna go za przydatny.

W moim przypadku to zakończenia linii DOS ( \r\nzamiast \n) potknęłyby #!/usr/bin/env pythonsię o potknięcie shebang line ( ). Prosty dos2unix myfile.pyto naprawił.

Otrzymałem ten sam błąd dla prostego skryptu bash, który nie miałby problemów z 32/64-bitami. Dzieje się tak prawdopodobnie dlatego, że skrypt, który próbujesz uruchomić, zawiera błąd. Ten post na forum Ubuntu wskazuje, że w przypadku zwykłych plików skryptów możesz dodać „sh” na początku i możesz uzyskać z niego dane debugowania. na przykład

$ sudo sh arm-mingw32ce-g++

i zobacz, czy uzyskasz jakieś wyjście.

W moim przypadku rzeczywisty problem polegał na tym, że plik, który próbowałem uruchomić, był w formacie Windows, a nie Linux.

Otrzymałem ten błąd, “No such file or directory”ale istnieje, ponieważ mój plik został utworzony w systemie Windows i próbowałem go uruchomić w systemie Ubuntu, a plik zawierał nieprawidłowy 15 \ r, gdziekolwiek był nowy wiersz. Właśnie utworzyłem nowy plik, obcinając niechciane rzeczy

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 

Poniższe polecenie działało na 16.4 Ubuntu

Ten problem pojawia się, gdy plik .sh jest uszkodzony lub nie został sformatowany zgodnie z protokołami unix.

dos2unix konwertuje plik .sh do formatu uniksowego!

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

Miałem ten sam problem z plikiem, który utworzyłem na moim Macu. Jeśli spróbuję uruchomić go w powłoce z ./filename otrzymuję komunikat o błędzie nie znaleziono pliku. Myślę, że coś było nie tak z plikiem.

co ja zrobiłem:

otwórz sesję ssh na serwerze
nazwa_pliku cat
skopiuj dane wyjściowe do schowka
rm nazwa_pliku
dotknij nazwa_pliku
vi nazwa_pliku
i dla trybu wstawiania
wklej zawartość ze schowka
ESC, aby zakończyć tryb wstawiania
: wq!

To zadziałało dla mnie.

Właśnie miałem ten problem mingw32 bash. Wykonałem węzeł / npm z, Program Files (x86)\nodejsa następnie przeniosłem je do disabledkatalogu (zasadniczo usuwając je ze ścieżki). Miałem też Program Files\nodejs(tj. Wersję 64-bitową) w ścieżce, ale dopiero po wersji x86. Po ponownym uruchomieniu powłoki bash można było znaleźć 64-bitową wersję npm. nodedziałał poprawnie przez cały czas (sprawdzane z node -vtą zmianą przy przenoszeniu wersji x86).

Myślę bash -r, że zadziałałoby zamiast ponownego uruchamiania basha: https://unix.stackexchange.com/a/5610

Jak wspominali inni, dzieje się tak, ponieważ nie można znaleźć programu ładującego, a nie pliku wykonywalnego. Niestety przesłanie nie jest wystarczająco jasne.

Możesz to naprawić, zmieniając program ładujący, którego używa twój plik wykonywalny, zobacz moją dokładną odpowiedź na to drugie pytanie: Wiele bibliotek glibc na jednym hoście

Zasadniczo musisz znaleźć program ładujący, którego próbuje użyć:

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

Następnie znajdź właściwą ścieżkę dla równoważnego modułu ładującego i zmień plik wykonywalny, aby używał modułu ładującego ze ścieżki, którą naprawdę jest:

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

Prawdopodobnie będziesz musiał ustawić również ścieżkę dołączeń, będziesz wiedział, czy chcesz, czy nie, po próbie uruchomienia. Zobacz wszystkie szczegóły w tym drugim wątku.

Znalazłam rozwiązanie dla mojego Ubuntu 18 tutaj .

sudo dpkg --add-architecture i386

Następnie:

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

Miałem ten problem, a przyczyną był EOL w niektórych edytorach, takich jak Notepad ++. Możesz to sprawdzić w menu Edycja / Konwersja EOL. Należy wybrać Unix (LF). Mam nadzieję, że to się przyda.

Dodano tutaj do wykorzystania w przyszłości (dla użytkowników, którzy mogą znajdować się w tym samym przypadku): Ten błąd występuje podczas pracy w systemie Windows (który wprowadza dodatkowe znaki z powodu innego separatora linii niż system Linux) i podczas próby uruchomienia tego skryptu (z wstawionymi dodatkowymi znakami) w Linuksie. Komunikat o błędzie jest mylący.

W systemie Windows separatorem linii jest CRLF ( \ r \ n ), podczas gdy w Linuksie jest to LF ( \ n ). Można to zwykle wybrać w edytorze tekstu.

W moim przypadku stało się to z powodu pracy w systemie Windows i przesyłania na serwer Unix w celu wykonania.