У мене є химерна, здавалося б, проблема з оболонкою, з командою в $ 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

Я бачу очікуваний вихід. Щось тут напевно плутає оболонку, але я втрачаю, що це може бути?

EDIT: пошук того, що було схоже на запитання: Бінарний файл не буде виконуватися під час запуску із контуром. Наприклад, програма ./ не працюватиме, але програма працює нормально

Я також перевірив більше ніж одну таку команду в моєму $ PATH, але знайшов лише одну:

# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand

EDIT2:

Станом на сьогодні вранці проблема зникла , і я зараз можу виконати виконуваний файл.

Це можна вважати валідуючим пропозицію вийти та увійти, але я це зробив минулої ночі без успіху. Цей вихід / логін також повинен був виконати еквівалент запуску запропонованої команди "hash -r" (яка fwiw також виглядає як вбудований ksh, а не просто вбудований bash).

У відповідь на деякі відповіді:

• Це виконуваний не сценарій (див. Посилання ELF у вихідному файлі команди).

• Я не думаю, що ця допомога допомогла б. Це в кінцевому підсумку змушує команду виконувати повністю кваліфіковано. Я припускаю, що я міг би виконати штрих приєднання до поточної оболонки, але оскільки я вже не можу докоряти, немає сенсу намагатися це робити.

• в $ PATH не було крапки з комою. Оскільки я більше не можу дорікати, я не буду перебирати це питання повною мірою $ PATH.

• спробувати іншу оболонку (тобто баш) було б чимось, що я б також спробував, як було запропоновано. З усуненою проблемою я зараз не знаю, чи допомогло б це.

Також мені було запропоновано перевірити дозволи довідників. Роблячи це, я бачу для кожного з каталогів до цього.

# 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 зіпсовано (не повинно бути кореневою групою). Це може спричинити інші проблеми, але я не бачу, як це спричинило б це.

Ви , ймовірно , необхідно оновити кеш командного інтерпретатора елементів у вашому $PATHвикористанні hash -r.

Крім того, у таких випадках перевірте, що відбувається при виклику програми, передаючи її виконуваний файл як аргумент динамічному лінкеру (може відмовитися від цього під час встановлення / setgid в деяких системах).

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

Ця поведінка змусила людей ошелешити, які були свідками закінчення епохи libc5, а тепер час від часу одурює людей в епоху змішаного i386 / amd64 з різними засобами підтримки двох бібліотечних наборів у дикій природі.

Відносна RPATH у виконанні проти $ PWD?

PS інше питання пов'язане з MacOSX, який, ймовірно, використовує dyld, а не libc, що надається лінкером. Дуже різний вид тварини.

Гаразд, у мене немає відповіді. Я довів кілька речей і думаю, що можу додати це до пізніше:

• Створено тестовий файл - ваші дозволи дозволяють встановити його та виконати.
• Спробував встановити його на точці кріплення з носуїдом: все ще працює
• Спробував встановити його на точці монтажу за допомогою noexec: дає іншу помилку

Тож, за всіма відомостями, я все ще такий розгублений. Тільки для посмішок і з випадковості це помилка, пов’язана з оболонкою, чи можете ви спробувати її з іншою оболонкою?

Я здогадуюсь, що ваш сценарій не має дійсної оболонки після # !. Наприклад, на деяких старих системах SCO сценарії з #! / Bin / bash не працюють, тому що bash дійсно живе в / usr / bin / bash. Тупий, але ей ШОС майже мертвий з причини, ні?

Перевірте свою оболонку та переконайтесь, що вона вказує на справжній бінарний / скрипт.

Редагувати: не вказується, чи це скрипт, чи двійковий файл, але якщо припустити, що ваш висновок '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.

Гммм ... Тож, можливо, сценарій не викликає правильної мови сценаріїв (перл, в даному випадку). У верхній частині сценарію є правильна магія:

#!/usr/bin/perl

і справді / usr / bin / perl існує і працює. Отже наступний дзвінок працює правильно.

/usr/bin/perl myscript.pl

Автозаповнення вкладки не відображатиме файл (ні в, tcshні в bash).

Це справді мене відкинуло. Потім згадав, що кілька місяців тому мій жорсткий диск вийшов з ладу, і молодий системний адміністратор у моїй лабораторії перевстановив систему. Думав, що він, можливо, накрутив дозволи на перегородки. І справді, /etc/fstabдозвіл на виконання не було!

/dev/sda1    /my     /ext4      rw,user

Замість

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

Виправлено це шляхом зміни /etc/fstabта перепланування:

mount -v -o remount /my

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

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

Перед командою вкладеного сценарію я роздрукував команду, наприклад, echo $ (що mycommand)

mycommand: / home / me / bin / mycommand

Тоді я б спробував виконати його з батьківського сценарію:

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

Як і запитуючий, я не зміг діагностувати джерело проблеми. Мій PATH виглядав правильно, це було можливо, а хеш не виявив жодних попередніх записів моєї команди. Наступного дня, коли я ввійшов у систему, все чарівно спрацювало знову. Тепер я зазначу, що існувала відома системна проблема, яка виникала якраз до того, як я побачив цю проблему, коли було перераховано кріплення. Можливо, це підказка?

Якби я не мав файл журналу після того, як файл журналу демонстрував, що це сталося, я б не вважав, що це було можливо! Завдяки питаючому, я більше не відчуваю божевілля!

PS Я не думаю, що користувач226160 мав точну проблему, як і репортер, але це звучить пов'язано і надає довіру теорії кріплення.