«Нет такого файла или каталога», но он существует

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

  file file-name # помог мне понять, что присутствует окончание CRLF  в файле.  

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

  dos2unix filename # действительно помогло мне, и все было хорошо.  

Я надеюсь, что нам следует проявлять осторожность при редактировании файлов на разных платформах, мы также должны заботиться о форматах файлов.

Эта ошибка также может возникать, если при попытке запустить сценарий написано с ошибкой 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.

Я получил эту ошибку «Нет такого файла или каталога» , но она существует, потому что мой файл был созданный в Windows, и я попытался запустить его в Ubuntu, и файл содержал недопустимый 15 r везде, где когда-либо была новая строка. Я только что создал новый файл, усекающий ненужные вещи

   sleep: недопустимый интервал времени '15  r'Попробуйте 'sleep --help' для получения дополнительной информации .script.sh: 5: script.sh:/opt/ag/cont: not foundscript.sh: 6: script.sh:/ opt/ag/cont: not foundroot @ Ubuntu14:/home/abc12/Desktop # vi script.sh root @ Ubuntu14:/home/abc12/Desktop # od -c script.sh 0000000 #! /usr/bin/env b0000020 ash  r  nwgethttp:/0000400: 4 1 2 0/ r  n0000410root @ Ubuntu14:/home/abc12/Desktop # tr -d \ 015  script.sh.  fixedroot @ Ubuntu14:/home/abc12/Desktop # od -c script.sh.fixed 0000000 #! /usr/bin/env b0000020 ash  nwgethttp://0000400/ n0000402root @ Ubuntu14:/home/abc12/Desktop # sh -x script.sh.fixed  

Команда ниже работала на Ubuntu 16.4

Эта проблема возникает, когда ваш файл .sh поврежден или не отформатирован в соответствии с протоколами unix.

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

  sudo apt-  получить установить dos2unix -ydos2unix test.shsudo chmod u + x test.sh sudo ./test.sh  

У меня была такая же проблема с файлом, который я создал на своем Mac. Если я попытаюсь запустить его в оболочке с ./filename, я получу сообщение об ошибке файл не найден Я думаю, что с файлом что-то не так.

что я сделал:

открыть сеанс ssh на сервере
cat filename
скопировать вывод в буфер обмена
rm filename
коснитесь имени файла
vi filename
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 [Запрос интерпретатора программы:/lib/ld-linux.so.2pting

Затем найдите правильный путь для эквивалентного загрузчика и измените свой исполняемый файл, чтобы использовать загрузчик из путь, которым он является на самом деле:

  $ ./patchelf --set-интерпретатор/path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g ++  

Возможно, вам также потребуется установить путь для включаемых файлов, вы узнаете, хотите вы этого или нет, после попытки его запустить. Смотрите все подробности в этом другом потоке.

Я нашел свое решение для моего Ubuntu 18 здесь.

  sudo dpkg --add-architecture i386  

Затем:

  sudo apt-get updatesudo 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 для выполнения.

Ударьте эту ошибку, пытаясь запустить terraform/terragrunt (Single go двоичный).

Используя which terragrunt , чтобы найти, где находится исполняемый файл, возникла странная ошибка при его запуске в локальном каталоге или с полным путем

  bash: ./terragrunt: нет такого файла или каталога  

Проблема заключалась в том, что было две установки terragrunt, использовались brew uninstall terragrunt , чтобы удалить один, исправленный.

После удаления одного, which terragrunt показал новый путь /usr/bin/terragrunt все работало нормально.

Вы уже перешли в каталог sbin, поэтому теперь вам нужно использовать

./start-dfs.sh

вместо

sbin/ start-dfs.sh

начать все. sh — это файл, а не каталог, для запуска таких файлов вы должны использовать ‘./’ перед исполняемым файлом,

попробуйте: ./start-all.sh