У меня странная проблема с оболочкой с командой в $ PATH, которую оболочка (ksh, работающая в Linux) трусливо отказывается вызывать. Без полной квалификации команды я получаю:
# mycommand
/bin/ksh: mycommand: not found [No such file or directory]
но можно найти файл, по которому:
# which mycommand
/home/me/mydir/admbin/mycommand
Я также явно вижу этот каталог в $ PATH:
# echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin
EXE в этом месте кажется нормальным:
# file /home/me/mydir/admbin/mycommand
/home/me/mydir/admbin/mycommand: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped
# ls -l mycommand
-r-sr-s--- 1 me mygroup 97892 2012-04-11 18:01 mycommand
и если я запустил его явно, используя полный путь:
# /home/me/mydir/admbin/mycommand
Я вижу ожидаемый результат. Что-то тут точно смущает оболочку, но я не понимаю, что это может быть?
РЕДАКТИРОВАТЬ: найти то, что похоже на аналогичный вопрос: Двоичный файл не будет выполняться при запуске с путем. Например> ./ программа не работает, но> программа работает нормально
Я также протестировал более одной такой команды в моем $ PATH, но нашел только одну:
# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand
РЕДАКТИРОВАТЬ2:
Сегодня утром проблема исчезла, и теперь я могу запустить исполняемый файл.
Это можно рассматривать как подтверждение предложения выйти из системы и войти в систему, но я сделал это прошлой ночью безуспешно. Этот выход / вход в систему также должен был выполнить эквивалент выполнения предложенной команды 'hash -r' (которая также является встроенной функцией ksh, а не только встроенной функцией bash).
В ответ на некоторые из ответов:
Это исполняемый файл, а не сценарий (см. Ссылку на ELF в выходных данных команды файла).
Не думаю, что strace помог бы. Это приводит к тому, что команда полностью выполняется. Я полагаю, что мог бы выполнить прикрепление strace к текущей оболочке, но, поскольку я больше не могу воспроизводить, нет смысла пробовать это.
в $ PATH нет точек с запятой. Поскольку я больше не могу воспроизводить репро, я не буду загромождать этот вопрос полным значением $ PATH.
Я бы тоже попробовал другую оболочку (например, bash), как было предложено. Теперь, когда проблема исчезла, я не знаю, помогло бы это.
Мне также было предложено проверять права доступа к каталогу. При этом для каждого из каталогов до этого я вижу:
# ls -ld $HOME $HOME/mydir $HOME/mydir/admbin
drwxr-xr-x 10 me root 4096 2012-04-12 12:20 /home/me
drwxrwsr-t 22 me mygroup 4096 2012-04-12 12:04 /home/me/mydir
drwxr-sr-x 2 me mygroup 4096 2012-04-12 12:04 /home/me/mydir/admbin
Право собственности на каталог $ HOME нарушено (не должно быть корневой группой). Это могло вызвать другие проблемы, но я не понимаю, как это могло вызвать эту.
Кроме того, в таких случаях проверьте, что происходит, когда программа вызывается, передав ее исполняемый файл в качестве аргумента динамическому компоновщику (в некоторых системах может отказаться делать это при setuid / setgid).
Вывод ldd (1) в обоих случаях также может быть показательным. «Нет такого файла или каталога» в исполняемом файле на самом деле означает, что динамический компоновщик, указанный в исполняемом файле, не может быть найден (представьте, что исполняемый файл имеет форму ELFin #! / lib / ld-linux.what.so.ever внутри)
Такое поведение ошеломляло людей, которые были свидетелями конца эры libc5, и теперь иногда ошеломляет людей в эпоху смешанного i386 / amd64 различными средствами поддержки двух наборов библиотек в дикой природе.
Относительный RPATH в исполняемом файле по сравнению с $ PWD?
PS другой вопрос связан с MacOSX, который, вероятно, использует dyld, а не предоставленный libc компоновщик. Очень разные животные.
Вам, вероятно, потребуется обновить кеш элементов в вашей оболочке. $PATH с помощью hash -r.
Хорошо, у меня нет ответа. Я действительно доказал несколько вещей и думаю, что могу добавить к этому позже:
Так что, судя по всему, я все еще в замешательстве. Просто для усмешки и на случай, если это ошибка, связанная с оболочкой, можете ли вы попробовать ее с другой оболочкой?
Я предполагаю, что у вашего скрипта нет допустимой оболочки после # !. Например, в некоторых старых системах SCO скрипты с #! / Bin / bash не работают, потому что bash ДЕЙСТВИТЕЛЬНО живет в / usr / bin / bash. Тупой, но эй, SCO почти умерла по какой-то причине, не так ли?
Проверьте свою оболочку и убедитесь, что она указывает на настоящий двоичный файл / скрипт.
Изменить: он не говорит, является ли это скрипт или двоичный файл, но если ваш вывод ls -l правильный, то у вас, вероятно, нет сценария 93 Кбайт ... так что это, вероятно, двоичный файл, означающий, что мой ответ совершенно неверно.
Вы пробовали выйти и снова войти? Я знаю, что если я использую двоичный файл, который находится в / usr / bin, а затем устанавливаю версию / usr / local / bin из источника, система все равно пытается выполнить исходную, пока я не выйду из системы и не вернусь.
Мои догадки:
У вас был псевдоним mycommand. Например:
alias mycommand=something
У вас была функция с именем mycommand. Например:
mycommand() { something; }
В следующий раз, когда у вас возникнет эта проблема, попробуйте запустить command -V mycommand чтобы увидеть, какой команде верит оболочка mycommand является.
Нет ответа, просто куча мыслей:
У меня была точно такая же проблема, и я не смог найти ответа, потому что проблема исходного плаката разрешилась сама собой. Но у меня это не сработало, и мне наконец удалось отследить проблему. Поэтому я добавляю следующее в качестве ответа на исходный пост.
Симптомы, с которыми я столкнулся, были следующими. В каталоге / 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
Это полностью решило проблему. Я предполагаю, что то же самое могло произойти с проблемой исходного плаката, за исключением того, что проблема с разрешением была прерывистой (например, было временное изменение, которое могло быть решено с помощью перезагрузки, если она имела место).
Не полный ответ, но хотел сообщить о своем опыте, поскольку у меня была точно такая же проблема, что и у спрашивающего, и я подумал, что это может помочь будущим пользователям столкнуться с той же раздражающей проблемой. Я мог бы получить файл и увидеть его на своем пути, и даже выполнить его, указав полный путь, но не мог бы выполнить его иначе. Однако в моем случае это происходило только внутри субоболочки (то есть когда оно было выполнено из скрипта, в этом случае было несколько вложенных субоболочек). Я мог бы запустить его из командной строки.
моякоманда: / главная / я / бен / моякоманда
/ home / me / bin / some_parent_script [72]: mycommand: not found [Нет такого файла или каталога]
Как и спрашивающий, я не смог диагностировать источник проблемы. Мой PATH выглядел правильно, это было возможно, и хэш не обнаружил никаких предыдущих записей mycommand. На следующий день, когда я зашел в систему, все снова волшебным образом заработало. Теперь я отмечу здесь, что была известная системная проблема, которая произошла незадолго до того, как я увидел эту проблему, когда монтирование было перемонтировано. Возможно, это ключ к разгадке?
Если бы у меня не было файла журнала после файла журнала, демонстрирующего, что это произошло, я бы не поверил, что это было возможно! Благодаря спрашивающему я больше не чувствую себя сумасшедшим!
P.S. Я не думаю, что user226160 имел ТОЧНУЮ ту же проблему, что и репортер, но это звучит взаимосвязанно и подтверждает теорию монтирования.