“Немає такого файлу чи каталогу”, але він існує

Я просто хочу запустити виконуваний файл з командного рядка ./arm-mingw32ce-g++, але тоді я отримую повідомлення про помилку,

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

Я працюю під Ubuntu Linux 10.10. ls -lсписки

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

Використання sudo ( sudo ./arm-mingw32ce-g++) дає

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

Я не уявляю, чому ОС навіть не може побачити файл, коли він там. Будь-які думки?

Ця помилка може означати, що ./arm-mingw32ce-g++вона не існує (але вона існує) або що вона існує і є динамічно пов'язаним виконуваним файлом, розпізнаним ядром, але динамічний завантажувач якого недоступний. Ви можете побачити, який динамічний навантажувач потрібен при запуску ldd /arm-mingw32ce-g++; що-небудь позначене not found- це динамічний завантажувач або бібліотека, яку потрібно встановити.

Якщо ви намагаєтеся запустити 32-розрядний двійковий файл на інсталяції amd64:

• Встановіть пакет до Ubuntu 11.04 ia32-libs.
• В Ubuntu 11.10 встановіть ia32-libs-multiarch.
• Починаючи з 12.04, встановіть ia32-libs-multiarchабо виберіть розумний набір :i386пакетів на додаток до :amd64пакетів.

Я зіткнувся з цією помилкою, коли намагався створити джерело Selenium на Ubuntu. Простий сценарій оболонки з правильним шебангом не міг працювати навіть після того, як я охопив усі попередні вимоги.

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

Я відкрив файл у Vim, і я міг переконатися, що лише тому, що я колись редагував цей файл на машині Windows, він був у форматі DOS. Я перетворив файл у формат Unix за допомогою команди нижче:

dos2unix filename # actually helped me and things were fine.

Я сподіваюся, що ми повинні подбати про те, коли ми редагуємо файли на різних платформах, ми повинні подбати і про формати файлів.

Ця помилка може також статися, якщо при спробі запустити сценарій і помилка написана в shebang . Переконайтеся , що він читає #!/bin/sh, #!/bin/bashабо в залежності від того перекладача ви використовуєте.

У мене було таке саме повідомлення про помилку при спробі запустити скрипт Python - це не було випадком використання @ Warpspace (див. Інші коментарі), але це було серед найпопулярніших звернень до мого пошуку, тому, можливо, комусь це буде корисно.

У моєму випадку це закінчення рядка DOS ( \r\nзамість \n), що лінія shebang ( #!/usr/bin/env python) зіткнеться. Простий dos2unix myfile.pyце виправив.

Я отримав ту ж помилку для простого скрипта bash, який не мав би 32/64-розрядних проблем. Можливо, це пов’язано з помилкою сценарію, який ви намагаєтесь запустити. Цей допис на форумі ubuntu вказує на те, що за допомогою звичайних файлів скриптів ви можете додати "sh" спереду, і ви можете отримати з нього деякі результати налагодження. напр

$ sudo sh arm-mingw32ce-g++

і подивіться, чи отримаєте ви якийсь результат.

У моєму випадку фактичною проблемою було те, що файл, який я намагався виконати, був у форматі Windows, а не в Linux.

Я отримав цю помилку, “No such file or directory”але вона існує, оскільки мій файл був створений в Windows, і я спробував запустити його на Ubuntu, і файл містив недійсні 15 \ r там, де був новий рядок. Я щойно створив новий файл, що скорочує небажані речі

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 

Нижче команда працювала на 16.4 Ubuntu

Ця проблема виникає, коли ваш файл .sh пошкоджений або не відформатований відповідно до протоколів unix.

dos2unix перетворює файл .sh у формат Unix!

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

У мене була та сама проблема з файлом, який я створив на своєму mac. Якщо я спробую запустити його в оболонці з ./filename, я отримаю повідомлення про помилку файлу не знайдено. Я думаю, що з файлом щось не так.

що я зробив:

відкрити сеанс ssh на сервер
cat ім'я файлу
скопіювати висновок у буфер обміну
rm ім'я файлу
touch ім'я файлу
vi ім'я файлу
i для режиму
вставки вставте вміст з буфера обміну
ESC до кінця режиму вставки
: wq!

Це спрацювало для мене.

Я щойно мав цю проблему в mingw32 bash. Я вилучив node / npm з, Program Files (x86)\nodejsа потім перемістив їх у disabledкаталог (по суті видаливши їх із шляху). У мене також був Program Files\nodejs(тобто 64-бітна версія) шлях, але лише після версії x86. Після перезапуску оболонки bash можна було знайти 64-бітну версію npm. nodeпрацював увесь час коректно (перевіряв із node -vзміненим при переміщенні версії x86).

Я думаю, він bash -rби працював замість перезапуску bash: https://unix.stackexchange.com/a/5610

Як згадували інші, це тому, що не можна знайти завантажувач, а не ваш виконуваний файл. На жаль, повідомлення недостатньо чітке.

Ви можете це виправити, змінивши завантажувач, який використовує ваш виконуваний файл, див. Мою ґрунтовну відповідь у цьому іншому питанні: Кілька бібліотек glibc на одному хості

В основному вам потрібно знайти, який завантажувач він намагається використовувати:

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

Потім знайдіть правильний шлях для еквівалентного завантажувача та змініть виконуваний файл, щоб використовувати завантажувач із шляху, яким він є насправді:

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

Ймовірно, вам також потрібно буде встановити шлях включень, ви будете знати, хочете ви цього чи ні, після спроби запустити його. Перегляньте всі подробиці в цій іншій темі.

Я знайшов своє рішення для мого Ubuntu 18 тут .

sudo dpkg --add-architecture i386

Тоді:

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

У мене була ця проблема, і причиною цього був EOL у деяких редакторах, таких як Notepad ++. Ви можете перевірити це в меню Редагування / перетворення EOL. Слід вибрати Unix (LF). Сподіваюся, це було б корисно.

Додано сюди для подальшого використання (для користувачів, які можуть потрапити в той самий випадок): Ця помилка трапляється під час роботи в Windows (яка вводить зайві символи через інший роздільник рядків, ніж система Linux) та спроби запустити цей сценарій (із вставленими зайвими символами) в Linux. Повідомлення про помилку вводить в оману.

У Windows роздільник рядків - CRLF ( \ r \ n ), тоді як у Linux це LF ( \ n ). Зазвичай це можна вибрати в текстовому редакторі.

У моєму випадку це сталося через роботу в Windows та завантаження на сервер Unix для виконання.