Назад | Перейти на главную страницу

исполняемый файл в пути, по которому его можно найти, но невозможно выполнить без полного указания пути?

У меня странная проблема с оболочкой с командой в $ 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).

В ответ на некоторые из ответов:

Мне также было предложено проверять права доступа к каталогу. При этом для каждого из каталогов до этого я вижу:

# 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.

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

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

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

Я предполагаю, что у вашего скрипта нет допустимой оболочки после # !. Например, в некоторых старых системах 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 является.

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

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

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

Симптомы, с которыми я столкнулся, были следующими. В каталоге / 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 $ (это моя команда)

моякоманда: / главная / я / бен / моякоманда

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

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

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

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

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