Вам, вероятно, потребуется обновить кэш элементов вашей оболочки в $ PATH , используя hash -r .

Хорошо, у меня нет ответа. Я доказал несколько вещей и думаю, что могу добавить к этому позже:

• Создал тестовый файл - ваши разрешения показывают, что он установлен и является исполняемым.
• Пытался установить его на точку монтирования с помощью nosuid: все еще работает
• Пытался установить его на точку монтирования с помощью noexec: выдает другую ошибку

Итак, судя по всему, я все еще не понимаю. Просто для усмешки и на случай, если это ошибка, связанная с оболочкой, можете ли вы попробовать ее с другой оболочкой?

Я предполагаю, что в вашем скрипте нет допустимой оболочки после # !. Например, в некоторых старых системах SCO скрипты с #! / Bin / bash не работают, потому что bash ДЕЙСТВИТЕЛЬНО живет в / usr / bin / bash. Тупой, но, эй, SCO почти мертв по какой-то причине, не так ли?

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

Редактировать: Он не говорит, скрипт это или двоичный, но если предположить, что ваш вывод 'ls -l' верен, то у вас, вероятно, нет 93-килобайтного скрипта ... так что это, вероятно, двоичный код, что означает, что мой ответ полностью неверен.

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

Нет ответа, только куча мыслей:

1. Проверить, не содержит ли имя файла пробелы; это незаметно игнорируется при использовании завершения по табуляции и использования в качестве параметра.
2. Попробуйте другой сценарий / программу в каталоге.
3. Попробуйте настроить оболочку, пытаясь выполнить сценарий, и посмотрите, где он прерывается.

Мои предположения:

• У вас было псевдоним mycommand . Например:

   псевдоним mycommand = something
  

• У вас была функция с именем mycommand . Например:

   mycommand () {что-то; }
  

В следующий раз, когда у вас возникнет эта проблема, попробуйте запустить command -V mycommand , чтобы узнать, что за команду интерпретирует оболочка mycommand .

Кроме того, в таких случаях проверьте, что происходит при вызове программы, передав ее исполняемый файл в качестве аргумента динамическому компоновщику (в некоторых системах может отказаться делать это при setuid / setgid).

Вывод ldd (1) в обоих случаях также может быть показательным. «Нет такого файла или каталога» в исполняемом файле на самом деле означает, что динамический компоновщик, указанный в исполняемом файле, не может быть найден (представьте, что исполняемый файл имеет форму ELFin #! / lib / ld-linux.what.so.ever внутри)

Такое поведение ошеломило людей, которые присутствовали там, чтобы стать свидетелями конца эры libc5, и теперь иногда ошеломляет людей в эпоху смешанного i386 / amd64 с различными средствами поддержки двух наборов библиотек в дикой природе.

Относительный RPATH в исполняемом файле vs $ PWD?

PS другой вопрос связан с MacOSX, который, вероятно, использует dyld, а не предоставленный libc компоновщик. Очень разные животные.

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

Я столкнулся со следующими симптомами. В каталоге / my / home есть скрипт (myscript.pl). каталог. Теперь пытаюсь запустить его:

> /my/home/myscript.pl
myscript.pl:  permission denied.

Проверено разрешение файла (установлен флаг выполнения). Проверено $ PATH (хотя проблем быть не должно).

Итак, я пробую (после проверки того, что в скрипте установлен флаг исполняемого файла):

> cd /my/home/
> ./myscript.pl:  permission denied.

Хммм ... Так что, возможно, скрипт вызывает неправильный скрипт язык (в данном случае Perl). В верхней части скрипта есть правильная магия:

#!/usr/bin/perl

и действительно / usr / bin / perl существует и работает. Таким образом, следующий вызов работает правильно: автозаполнение вкладки

/usr/bin/perl myscript.pl

не отображало файл (ни в tcsh , ни в bash ).

Это меня действительно сбило с толку. Потом вспомнил, что несколько месяцев назад у меня сломался жесткий диск, и молодой системный администратор в моей лаборатории переустановил систему. Думал, что может облажались с разрешениями на разделы. И действительно, в / etc / fstab отсутствовало разрешение exec!

/dev/sda1    /my     /ext4      rw,user

Вместо

/dev/sda1    /my     /ext4      rw,user,exec

Исправлено путем изменения / etc / fstab и повторного монтирования:

mount -v -o remount /my

Это решил проблему полностью. Я предполагаю, что похожая вещь могло произойти с проблемой исходного плаката, за исключением того, что там проблема с разрешением была прерывистой (например, произошло временное изменение это могло быть решено перезагрузкой, если бы она имела место).

Не полный ответ, но хотел сообщить о своем опыте, поскольку у меня была точно такая же проблема, что и у спрашивающего, и я подумал, что это может помочь будущим пользователям столкнуться с той же раздражающей проблемой. Я мог бы получить файл и увидеть его на своем пути, и даже выполнить его, указав полный путь, но не мог бы выполнить его иначе. Однако в моем случае это произошло только внутри субоболочки (т.е. когда он был выполнен из скрипта, в этом случае было несколько вложенных субоболочек). Я мог бы запустить его из командной строки.

Непосредственно перед командой во вложенном скрипте я распечатал команду, например echo $ (which mycommand)

mycommand: / home / me / bin / mycommand

Затем я бы попытался выполнить его из родительского скрипта:

/ home / me / bin / some_parent_script [72]: mycommand : not found [Нет такого файла или каталога]

Как и спрашивающий, я не смог диагностировать источник проблемы. Мой PATH выглядел правильно, это было возможно, и хэш не обнаружил никаких предыдущих записей mycommand. На следующий день, когда я зашел в систему, все снова волшебным образом заработало. Теперь я отмечу здесь, что была известная системная проблема, которая произошла незадолго до того, как я увидел эту проблему, когда монтирование было перемонтировано. Возможно, это ключ к разгадке?

Если бы у меня не было файла журнала за файлом журнала, демонстрирующего, что это произошло, я бы не поверил, что это было возможно! Благодаря спрашивающему я больше не чувствую себя сумасшедшим!

P.S. Я не думаю, что user226160 имел ТОЧНУЮ ту же проблему, что и репортер, но это звучит взаимосвязанно и подтверждает теорию монтирования.