Коли файл виконується, як Unix шукає його? Якщо в PATH є кілька виконуваних файлів з тим самим іменем, який із них є кращим? Чи включається поточний каталог у пошук при виконанні файлу?
Припустимо, executable.shу поточному каталозі є файл з ім'ям . Чи буде це працювати, якщо він буде виконаний $ executedі .не є частиною PATH?
Відповіді:
Пошук у $ PATH проводиться від початку до кінця, запускається перший виконуваний файл відповідності. Тож каталоги на початку $ PATH мають перевагу над тими, що з’являються пізніше. Виконавчі файли в поточному каталозі (.) Виконуються лише якщо. знаходиться в $ PATH (що зазвичай це не так ). Немає чіткого включення поточного каталогу у шлях пошуку.
., але, здається, спочатку шукатимуть з поточного dir, перш ніж перевірити dirs, визначений у самому $ PATH.
Для файлів у поточному каталозі ви хочете передувати їм ./, тому команда стане ./executable.sh. Ви ніколи не повинні мати .у своєму складі PATH, оскільки це становить загрозу безпеці, серед інших проблем.
Довідники, які приходять першими в PATH і шукають першими.
Загальний порядок для пошуку, як це , якщо я правильно пам'ятаю:
псевдоніми
експортовані функції
вбудовані команди оболонки
сценарії та двійкові файли у вашому PATH
hash -r), якщо ви змінили місця PATH або програми.
Хоча деякі інші відповіли на це добре, я хотів би додати кілька думок:
1) Консультація з PATH проводиться лише в тому випадку, якщо в запущеному файлі файлів немає елементів шляху. деякийкоманд буде шукати в $ PATH, ./somecommandабо /usr/bin/somecommand, або ../../bin/somecommandпросто використовувати правила каталогу, а не PATH
Якщо в PATH є кілька виконуваних файлів з тим самим іменем, який із них є кращим?
Він зупиняється на першому, який знайде, читаючи $ PATH зліва направо.
Чи включається поточний каталог у пошук при виконанні файлу?
Якщо поточний каталог знаходиться в PATH, тоді його шукають. Пам'ятайте, що порожній каталог у PATH включає поточний каталог. напр., PATH =: / usr / bin (ведучий порожній) PATH = / usr / bin: (трейлінг порожній) та PATH = / usr / bin :: / bin (середній порожній) ефективно включатимуть поточну робочу директорію.
Припустимо, у поточному каталозі є файл з ім'ям Executable.sh. Чи буде це працювати, якщо він буде виконаний $ Executed і. не є частиною ПАТУ?
Він ніколи не знайде його шляхом пошуку PATH. Якщо поточного dir немає в PATH, він не знайде його за допомогою PATH пошуку.
Це сказало (і, на жаль, додайте плутанини), якщо був би псевдонім або функція, яка виконувала команду, вона буде запущена. Або якщо у вашій оболонці був кеш місцеположення, а виконуваний файл був у кеші, він може його знайти. Отже, він ніколи не знайде його в PATH, але він може бути запущений іншими способами.
cacheзауваження, це майже зводить мене з розуму, що старий виконуваний файл /usr/bin/все ще викликається не новим /usr/local/bin, однак він знаходиться ліворуч до тих $PATHпір, поки я не вийшов із системи та ввійшов знову.
Щоб побачити, який ваш шлях наразі просто введіть echo $PATH, або printenv PATH.
Тоді ви дізнаєтесь порядок пошуку. Якщо у вас є кілька файлів з одним іменем, просто запустіть, який ____ переглянути.
Вих.
система #> який греп
/ usr / bin / grep
Класний спосіб пошуку файлів, які працюють як ваша мета, - це використовувати apropos:
apropos grep
bzgrep (1) - пошук, можливо, стислих файлів bzip2 для регулярного виразу
egrep (1) - друкувати лінії, що відповідають шаблону
fgrep (1) - друкувати лінії, що відповідають шаблону
grep (1) - друкувати лінії, що відповідають шаблону
і так далі...
whereisвикористовує твердо кодований список місць, не $PATH.
@ coneslayer - Типовим порядком пошуку виконавчого файлу є поточний шлях, вбудований у команди, а потім $ PATH. Отже, якщо функція з назвою виконується вже існує в pwd, то вона виконується. Якщо не тоді, пріоритет шукає вбудовані команди оболонки, а потім $ PATH
./), вона шукає лише цей каталог; в іншому випадку він здійснює пошук $PATH.
which <executable>Команда згадування буде корисна в цій темі.