Переменная PATH в Linux
Когда вы запускаете программу из терминала или скрипта, то обычно пишете только имя файла программы. Однако, ОС Linux спроектирована так, что исполняемые и связанные с ними файлы программ распределяются по различным специализированным каталогам. Например, библиотеки устанавливаются в /lib или /usr/lib, конфигурационные файлы в /etc, а исполняемые файлы в /sbin/, /usr/bin или /bin.
Таких местоположений несколько. Откуда операционная система знает где искать требуемую программу или её компонент? Всё просто — для этого используется переменная PATH. Эта переменная позволяет существенно сократить длину набираемых команд в терминале или в скрипте, освобождая от необходимости каждый раз указывать полные пути к требуемым файлам. В этой статье мы разберёмся зачем нужна переменная PATH Linux, а также как добавить к её значению имена своих пользовательских каталогов.
Переменная PATH в Linux
Для того, чтобы посмотреть содержимое переменной PATH в Linux, выполните в терминале команду:
На экране появится перечень папок, разделённых двоеточием. Алгоритм поиска пути к требуемой программе при её запуске довольно прост. Сначала ОС ищет исполняемый файл с заданным именем в текущей папке. Если находит, запускает на выполнение, если нет, проверяет каталоги, перечисленные в переменной PATH, в установленном там порядке. Таким образом, добавив свои папки к содержимому этой переменной, вы добавляете новые места размещения исполняемых и связанных с ними файлов.
Для того, чтобы добавить новый путь к переменной PATH, можно воспользоваться командой export. Например, давайте добавим к значению переменной PATH папку/opt/local/bin. Для того, чтобы не перезаписать имеющееся значение переменной PATH новым, нужно именно добавить (дописать) это новое значение к уже имеющемуся, не забыв о разделителе-двоеточии:
Теперь мы можем убедиться, что в переменной PATH содержится также и имя этой, добавленной нами, папки:
Вы уже знаете как в Linux добавить имя требуемой папки в переменную PATH, но есть одна проблема — после перезагрузки компьютера или открытия нового сеанса терминала все изменения пропадут, ваша переменная PATH будет иметь то же значение, что и раньше. Для того, чтобы этого не произошло, нужно закрепить новое текущее значение переменной PATH в конфигурационном системном файле.
В ОС Ubuntu значение переменной PATH содержится в файле /etc/environment, в некоторых других дистрибутивах её также можно найти и в файле /etc/profile. Вы можете открыть файл /etc/environment и вручную дописать туда нужное значение:
sudo vi /etc/environment
Можно поступить и иначе. Содержимое файла .bashrc выполняется при каждом запуске оболочки Bash. Если добавить в конец файла команду export, то для каждой загружаемой оболочки будет автоматически выполняться добавление имени требуемой папки в переменную PATH, но только для текущего пользователя:
Выводы
В этой статье мы рассмотрели вопрос о том, зачем нужна переменная окружения PATH в Linux и как добавлять к её значению новые пути поиска исполняемых и связанных с ними файлов. Как видите, всё делается достаточно просто. Таким образом вы можете добавить столько папок для поиска и хранения исполняемых файлов, сколько вам требуется.
Источник
export PATH
Вопрос касается export. Export превращает локальную переменную в переменную окружения. В bashrc есть такая строчка —
нахрен здесь export? ведь PATH и так переменная окружения. Я раньше думал, что для того, чтобы и значение этой переменной экспортнулось, но сегодня заметил, что и без export дочерняя сессия получает это значение — допустим, если написать
то значение будет ru_RU.UTF-8 без всякого экспорта.
То есть, как я понял, export просто превращает локальную переменную в переменную окружения и смысла его запускать для уже существующих переменных окружения нет, то есть бессмысленно писать export PATH, но зачем-то он везде прописан? ладно, предположим, что PATH до этого не задана но ведь сама переменная PATH=$PATH:/foo:/bar намекает, что используй существующую переменную PATH.
Ну старо же как мир.
Предположение — чушь. И это не дистроспецифично. bash, он и во фряхе bash.
У других шеллов ситуация схожая.
Почему никто не читает, что речь идет о заданных переменных среды,которые уже были экспортнуты, а не локальных?
/.bashrc указана переменная PATH=$PATH:/home/user/bin…., что обыденная ситуация, чтобы пользователь мог указывать свои директории для запуска программ. Но после этой переменной стоит export PATH. export нужен для локальных переменных, а вот экспортить уже переменные среды бессмысленно. Но почему-то эта надпись есть.
Кто-то на форуме указал, что это нужно для превентивной защиты от дураков, мол если вдруг не задана переменная окружения PATH, то отсюда она задастся. Но если не задана переменная PATH, то в файле
/.bashrc она примет значение PATH=:/home/user/bin, а каким образом это защитит от дураков мне так никто и не ответил.
Кто-то сказал, что на Солярисе нужно вручную указывать export, если меняется переменная среды, но речь вовсе не про Солярис.
Кто-то ударился в объяснения разницы между
/.bashrc, но я как-бы не об этом спрашивал.
Переменная PATH не простро экспортированная. Она читается шеллом отдельно(man bash). И тут не важно, есть export или нет.
… можно просто ответить на мой вопрос — зачем нужно было в
/.bashrc писать export PATH? Хоть кто-нибудь..
Простите, но я треть жизни работаю на линукс и сегодня весь день потратил время в поиске ответа на этот вопрос, но вместо ответа на него мне рассказывают про bash_profile, локальные переменные и PATH.
Неужели я неясно поставил вопрос? Повторю на всякий случай. Зачем в
/.bashrc надпись export PATH ?
Мне не нужно объяснять ничего другого. Просто ответ на этот вопрос.
недостаточно пароноидально. Нужно как-то так:
Откройте терминал и сделайте команды:
В выводе от последней команды осталось «aaa»? Только, если у вас bash по другому пути, то пишите его, вместо /bin/bash.
Я не знаю, какой у вас bash, может патченный. Обычный bash, запускаемый без переменной среды PATH создаст bash-переменную PATH и определит её в значение по умолчанию. Но, так как переменной среды PATH нет, то bash-переменная не будет экспортируемой, то есть не будет определять переменную среды для дочерних процессов.
Речь идет об обычном десктопном Centos8, где в /etc/profile есть надпись export PATH. То есть PATH уже задан как переменная среды еще до того, как прочесть
Тут уже 10 раз написали, что это для совместимости с самым общим posix shell. И заметь, export идет отдельной строкой, а не export VAR=. — это тоже для совместимости. Потому что profile будет\должен быть загружен в любой запущенный тобой шелл, не только баш.
И я все еще сомневаюсь, что PATH штатно устанавливается в bashrc, а не profile. Это было бы криво, http://superuser.com/a/789465
Export превращает локальную переменную в переменную окружения.
В вашей терминологии «локальная переменная» тоже является переменной окружения, но текущего процесса. Она невидима дочерним процессам.
export делает переменную окружения текущего процесса видимой дочерним процессам.
Дочерний процесс не может изменить переменную окружения родительского процесса.
Вы какую-то фигню написали.
export делает переменную окружения текущего процесса видимой дочерним процессам.
test1 = локальная переменная. Но export делает её видимой дочерним процессам. А значит export делает локальную переменную видимой дочерним процессам
Дочерний процесс не может изменить переменную окружения родительского процесса.
я где-то утверждал обратное?
Пожалуйста, взгляните на скриншот: https://imgur.com/KC7xdxI
Стандартный Centos8. В файле /etc/skel/.bashrc, который штатно копируется в домашнюю директорию пользователей при их создании, есть PATH и export PATH. Если вам кажется, что я это подделал, можете поискать в интернете или даже сами развернуть виртуалку и проверить.
Я запустил штатную /usr/bin/sh. Это «When Bash, mksh and zsh are invoked with the sh name, they automatically become more POSIX compliant. «, установленный в Centos 8. Сначала я вывел текущий PATH. Затем изменил его ( PATH=/usr/bin, /usr/sbin/ ). Не сделал экспорт, но запустил дочерний sh. В нём я проверил, получила ли дочерняя сессия изменённое значение переменной PATH без экспорта — и да, там я увидел измененное. То есть для встроенного sh, который стал дочерним процессом, от самого же sh всё нормально передалось и без повторного export, то есть export PATH не нужен был. Не значит ли это, что он либо не posix совместим, либо posix shell тоже так умеет?
Если вы говорите для совместимости, то приведите пример, чтобы я понял, где этот export в
/.bashrc прям необходим и где что сломается без него?
А там скорее всего ссылка символическая на bash || dash || ash || что-то еще, так что ты запустил далеко не каноничный sh.
давай ка ты нам покажешь ls -lha /usr/bin/sh для начала.
завязывай свой тупняк, тебе уже прекрасно написали для чего нужен export, а ты все предлагаешь закладываться на поведение какого-то конкретного дистрибутива в надежде что такое поведение везде.
В комменте выше я сказал, что sh — это When Bash, mksh and zsh are invoked with the sh name, they automatically become more POSIX compliant. «, если вы не поняли, там bash.
Тупняк у вас, я спрашиваю, почему так написано, это не имеет значения, не важно, написано это в одном дистре или во всех. Да хоть в одном центос, можно просто ответ на мой вопрос, зачем?
Если речь о совместимости, пришлите скриншот, где вы не сделали export и все поломалось. А потом объясните, почему это нужно в Centos, ведь дефолтный шелл там баш, а на zsh это тоже работает как на bash
Такая никак, т.к. это уже даже не дурак, подобным ты еще и весь существующий PATH затираешь, но это ты понять вполне способен.
Не передергивай это защита от дурака, на случай когда по какой-то причине PATH не была вообще проэкспортирована в окружение, и в данном случае даже с таким PATH тот софт который закладывается на этот путь в PATH будет исправно работать. Как я написал ранее это конечно не спасет другой софт для которого ты затер пути которые были в PATH до этого.
И где написано, что bash, вызванный как interactive shell будет читать /etc/profile? Или считаете, что bash может быть запущен только эмулятором терминала?
Вы в терминале какие-нибудь программы, кроме mc запускали? Допустим less? В less можно не выходя запустить какую-нибудь команду, допустим ! ls -l . less вызовет bash, чтобы тот вызвал ″ls -l″. Это не будте login shell. less не обязан выставлять PATH.
Это было бы справедливо, будь в этом пути что-то кроме /home/user/bin и /home/user/.local/bin . Но речь про дефолтные настройки в Centos 8. Если по какой-то причине PATH до этого не была проэкспортирована, то, полученная запись PATH=:/home/user/bin ничего не изменит. А значит ваша теория о защите от дурака не совсем подходит для конкретно этой ситуации.
Откуда вы взяли, что будет
я ведь привёл команды, показывающие что будет, если нет переменной окружения PATH.
Выше была ссылка на ютуб канал, там стримов на часов 20, наверное. Если вы хоть в одном увидите mc, ваши слова не будут пустым вбросом.
Пример с less так себе, потому что попробуйте сделать ! echo $PATH и поймёте.
Опять же, давайте мне реальный пример со скриншотом про тот вопрос, который я задал — зачем в
/.bashrc export PATH. То есть, вы утверждаете, что он какие-то программы, запущенные вне интерактивного шелла, не увидят переменную PATH без этой записи (
/.bashrc export PATH). Давайте я уберу этот export, а вы подскажите команды, чтобы я запустил или сами их запустите и пришлите скриншот. Когда я увижу, что будет разница между ситуациями, где этот export прописан и не прописан, я пойму.
Ну так что ты хочешь, там не sh, а bash, это «немного разные» командные оболочки, хоть и родственные.
Я вряд ли найду тебе сейчас где-то каноничный sh про который тебе говорили, потому что в большинстве нынешних реализаций это любой другой аналог. Но это не говорит о том, что ты не можешь его встретить в природе.
Да и уж прости, для того чтобы тебе доказать что-то, никто не будет чего-то искать и приводить примеры, тем более ты инициатор, так что бремя ответственности доказательства лежит на тебе, ты в принципе если бы не был троллем мог бы просто как нормальный человек почитать ответы и с некоторой степенью доверия принять их, тем более, что каждый из них логичный, но ты продолжаешь упираться оправдывая свой тупняк и искать какие-то доказательства того, что поведение по умолчанию для одного конкретного дистрибутива будет работать и для всех остальных. Тебе сказали что не будет, что ты еще хочешь? Не веришь, вперед устанавливай все доступные Unix и Unix-like ОС и проверяй.
Ну и достаточно легко загуглить что стандарты posix, что исходные тексты известных шеллов чтобы понять, кто и в какой мере из них поддерживает этот posix. Опять же стоит понимать что sh в его каноничном виде появился в 1977 году, а первые стандарты posix в 1988. Так что есть реализации sh которые вообще не удовлетворяют posix разве что так вышло что они ему удовлетворяют по той причине что эти стандарты писались с оглядкой на уже имеющееся окружение.
Ну во-первых надо ссылки кидать когда что-то цитируешь, далеко не каждый источник вызывает доверие. Во-вторых, это похоже на правду, в-третьих, что вызывает недоумение?
это не имеет значения, не важно, написано это в одном дистре или во всех.
Если речь о совместимости, пришлите скриншот, где вы не сделали export и все поломалось.
Читайте выше о бремени доказательства. Ну и у вас вообще какая-то поломанная логика, почему export должен что-то ломать? прочитайте уже man страницу export, поломать можете только вы что-то своими действиями, а экспорт просто экспортирует имя в окружение и не более.
Я вам уже раза 4 точно сказал для чего нужен экспорт, но вы упорно продолжаете настаивать на том, что раз в конкретном дистрибутиве при его инициализации за вас уже проэкспортировали PATH в окружение, а каждая новая сессия командной оболочки вытягивает заново эту инициализацию, то вроде как можно и не экспортировать ничего повторно, а просто править текущий PATH. Но это порочная практика завязанная на конкретный дистрибутив, пример с камерой я вам давал и если вы запорите там PATH восстановить его можно будет только перезапуском скриптов инициализации, т.е. считай перегрузить камеру, также вам давали понять что каноничный sh работает иначе в ряде случаев возможно и экскорт там работает иначе, это вопросы к любителям старины.
Но речь про дефолтные настройки в Centos 8.
Вся суть вашего спича, сколько раз мне нужно повторить это чтобы вы поняли что где-то может быть иначе?
Сколько раз мне повторять, что я знаю, что на других дистрах по-другому, но я спрашиваю про смысл этой надписи в Centos 8?
У меня на работе есть AIX, проверю на нём. Но даже если это справедливо для каких-то древних юниксовых sh, какой смысл давать эту совместимость в Centos 8, при том, что этой записи нет в других дистрах, даже в Centos 7, судя по словам одного из отписавшихся. Хотя я это тоже проверю
А теперь перечитайте свой изначальный пост, там нет ни слова про Centos 8 и конкретную завязанность на нем. Ты это начал использовать чтобы и дальше продолжать свой троллинг и иметь хоть какое-то оправдание тупняку. По факту тебе уже сказали для чего нужен повторный экспорт и почему его лучше писать чем не писать.
смысл в том, что ты никогда не знаешь на какой целевой системе будут запускать твои скрипты, и лучше делать защиту от дурака чем ее не делать и закладываться на какое-то поведение.
Как же с вами сложно. Потому что мой изначальный пост был про вопрос, нафига переменную среды повторно экспортить, в частности PATH. На что мне начали писать вообще ответы на несвязанные темы или вообще говорить, что в bashrc такого не пишут. Тогда я привёл пример, что вот Centos 8 так написано. Мне начали объяснять, что в других дистрах не так, вместо того, чтобы ответить на мой первый вопрос. Поэтому я всё упростил до максимально простого вопроса — зачем было экспорить path в одном только centos. Если кто-то объяснит хотя бы это, я получу ответ и на свой основной вопрос.
Теперь мне говорят, что «лучше писать, чем не писать». А тогда почему на других дистрах не пишут? Да и смысла в такой защите я просто не увидел. Хорошо, это защита на случай, если PATH не переменная среды. Как это защитит, ведь PATH получится бессмысленный (в случае с PATH, указанным в Сentos 8).
Это справедливо для скриптов, но не для переменной PATH в
/.bashrc. Причём здесь скрипты и export PATH в
Сколько ты там говоришь у тебя лет работы в unix окружении? Позволь тебе задать вопрос, является ли profile и bashrc скриптами?
В общем-то можешь не отвечать. Относительно твоего вопроса ты получил ответ.
Эм, и часто вы видели, чтобы кто-то закидывал profile и bashrc с какого-нибудь Centos 8 на какой-нибудь Solaris?
Кстати, проверил на AIX. Всё работает без export (для тех, кто говорил для совместимости с sh) https://ibb.co/41yZc7C
Это так не работает. В ядре, точнее во многих UN*X, давно сделано, что можно запустить файл без shebang (#!) и такой файл будет отдан на выполнение shell’ом. Что сломается, если это убрать из ядра? Да никто не знает, скорее всего, всё будет работать, но это не убирают. При этом везде написано, что скрипт обязательно должен начинаться с shebang.
Я не знаю конкретных примеров софта, который запускает /bin/bash без переменной среды PATH, может его такого в продакшене и нет, может это какая специфичная для RH поделка. Понятно, что там должна быть цепочка, что сначала запускается /bin/bash без PATH, а из него вызывается ещё что-то, которому нужно в PATH наличие
Считаете, что ″export PATH″ является багом — пишите в багзилу.
Я не говорю что это баг, я не считаю, что чувак, который написал это в
/.bashrc написал это просто так. Я просто хочу понять, зачем это сделано?
Ответы для совместимости с sh меня не убедили — проверил на AIX-овском shell, проверил на dash, на zsh — всё работает и без export.
Ответы «для защиты от случаев, если PATH не задалась как переменная среды» тоже не до конца понятны, потому что в таком случае мы получаем запись PATH=:/home/user/bin, а это не то чтобы спасает ситуацию. Всё равно что на отрезанную ногу пластырь накладывать.
Я просто хочу понять, зачем это сделано?
По-привычке. Проще запомнить ‘везде пишем export’, чем ‘пишем экспорт кроме случаев «список из 25 системоспецифичных исключений»’.
Хотелось бы увидеть хотя бы 1 пример, где не указанный export что-то ломает.
Источник
