Переменная окружения $PATH в linux
Когда в консоли Debian мы вводим какую-то команду или функцию, откуда он знает, где она лежит, как находит и запускает её или не находит и выдаёт ошибку? Объясняется это тем, что есть переменная, в которой хранятся пути до папок, в которых происходит поиск введённой команды (функции или скрипта). И если *nix находит соответствие заданному запросу, то запускает эту команду на исполнение (с дополнительными параметрами, если они введены) или выдаёт ошибку: «Пичалька, всё обыскал, но не понимаю, о чём ты спрашиваешь и чего хочешь.»
Как посмотреть значение переменной $PATH в Линукс
Для того, чтобы увидеть, какие папки при поиске заданной команды Линукс обходит в её поиске, достаточно вывести её значение с помощью команды echo :
В результате получим список директорий (папок), в которых предположительно могут находиться запрашиваемые команды или программы, например:
Как видно на примере выше, если список директорий состоит из более чем одной папки, они разделяются между собой символом двоеточия : .
Таким образом, можно понять, в каких папках Unix поискал (и не нашёл) нужной команды или программы, при неудачном стечении обстоятельств и тихо ругнулся:
Однако, если данная команда и/или программа существует и вы точно знаете, где она лежит, можно прописать до неё путь (относительный или абсолютный) и тогда она отработает свой сценарий:
Где хранится значение переменной $PATH ?
Значение переменной $PATH (список папок) вычисляется в файле /etc/profile .
В некоторых источниках пишут ещё при использовании файла /etc/environment .
Где ещё применяется значение переменной $PATH в linux?
В linux могут использоваться различные языки программирования и для того, чтобы система могла понимать, какой интерпретатор использовать при выполнении программного кода, в начале после знака # используется путь до него. Если по этому пути ничего не найдено, то при запуске такого кода тоже будет выдана ошибка.
Так, например, bash-скрипты начинаются строчкой:
А скрипты на языке программирования Perl, такой:
Резюме
Таким образом становится предварительно понятно, как происходит эта магия того, что компьютер может отвечать на какие-то запросы, выполняя требуемые действия при вводе определённых команд. 😉
Заберите ссылку на статью к себе, чтобы потом легко её найти!
Выберите, то, чем пользуетесь чаще всего:
Sorry, you have been blocked
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
Cloudflare Ray ID: 7d99d4063aea2313 • Your IP: Click to reveal 88.135.219.175 • Performance & security by Cloudflare
How to set your $PATH variable in Linux
Thomas Hendele on Pixabay (CC0). Modified by Opensource.com. CC BY-SA 4.0.
Being able to edit your $PATH is an important skill for any beginning POSIX user, whether you use Linux, BSD, or macOS.
When you type a command into the command prompt in Linux, or in other Linux-like operating systems, all you’re doing is telling it to run a program. Even simple commands, like ls, mkdir, rm, and others are just small programs that usually live inside a directory on your computer called /usr/bin. There are other places on your system that commonly hold executable programs as well; some common ones include /usr/local/bin, /usr/local/sbin, and /usr/sbin. Which programs live where, and why, is beyond the scope of this article, but know that an executable program can live practically anywhere on your computer: it doesn’t have to be limited to one of these directories.
More Linux resources
When you type a command into your Linux shell, it doesn’t look in every directory to see if there’s a program by that name. It only looks to the ones you specify. How does it know to look in the directories mentioned above? It’s simple: They are a part of an environment variable, called $PATH, which your shell checks in order to know where to look.
View your PATH
Sometimes, you may wish to install programs into other locations on your computer, but be able to execute them easily without specifying their exact location. You can do this easily by adding a directory to your $PATH. To see what’s in your $PATH right now, type this into a terminal:
You’ll probably see the directories mentioned above, as well as perhaps some others, and they are all separated by colons. Now let’s add another directory to the list.
Set your PATH
Let’s say you wrote a little shell script called hello.sh and have it located in a directory called /place/with/the/file. This script provides some useful function to all of the files in your current directory, that you’d like to be able to execute no matter what directory you’re in.
Simply add /place/with/the/file to the $PATH variable with the following command:
You should now be able to execute the script anywhere on your system by just typing in its name, without having to include the full path as you type it.
Set your PATH permanently
But what happens if you restart your computer or create a new terminal instance? Your addition to the path is gone! This is by design. The variable $PATH is set by your shell every time it launches, but you can set it so that it always includes your new path with every new shell you open. The exact way to do this depends on which shell you’re running.
Not sure which shell you’re running? If you’re using pretty much any common Linux distribution, and haven’t changed the defaults, chances are you’re running Bash. But you can confirm this with a simple command:
That’s the «echo» command followed by a dollar sign ($) and a zero. $0 represents the zeroth segment of a command (in the command echo $0, the word «echo» therefore maps to $1), or in other words, the thing running your command. Usually this is the Bash shell, although there are others, including Dash, Zsh, Tcsh, Ksh, and Fish.
For Bash, you simply need to add the line from above, export PATH=$PATH:/place/with/the/file, to the appropriate file that will be read when your shell launches. There are a few different places where you could conceivably set the variable name: potentially in a file called
/.profile. The difference between these files is (primarily) when they get read by the shell. If you’re not sure where to put it,
/.bashrc is a good choice.
For other shells, you’ll want to find the appropriate place to set a configuration at start time; ksh configuration is typically found in
/.zshrc. Check your shell’s documentation to find what file it uses.
This is a simple answer, and there are more quirks and details worth learning. Like most everything in Linux, there is more than one way to do things, and you may find other answers which better meet the needs of your situation or the peculiarities of your Linux distribution. Happy hacking, and good luck, wherever your $PATH may take you.
This article was originally published in June 2017 and has been updated with additional information by the editor.
Как дебажить переменные окружения в Linux
Часто бывает так, что приходишь на машину и обнаруживаешь какой-то скрипт, запущенный под системным пользователем неделю назад. Кто его запустил? Где искать этот run.php? Или добавляешь запись в /etc/crontab, а скрипт там падает с ошибкой «command not found». Почему? И что делать?
У меня есть ответы на эти вопросы.
Переменные окружения
Практически во всех современных операционных системах у процессов существуют переменные окружения. Технически они представляют собой набор именованных строк. Если запускается подпроцесс, то он автоматически наследует копию окружения родителя.
Среди прочих есть переменная PATH, которая указывает пути для поиска исполняемых файлов, переменная HOME, которая указывает на домашнюю директорию пользователя, переменные, отвечающие за языковые предпочтения пользователя, и многие другие.
Есть множество обзоров, описывающих значения этих переменных, а вот статей о том, как расследовать проблемы, практически нет. Восполним этот пробел.
Кто запустил процесс?
Итак, мы обнаружили скрипт, запущенный под системным пользователем неделю назад. Кто его запустил? Зачем? Может, про него просто забыли? Запустить его потенциально могли человек 10–15, всех не опросишь. Как найти, кто же это был? И где лежит этот run.php?
На помощь приходят переменные окружения процесса и особенность sudo. Есть такая переменная PWD, в которой оболочка хранит текущую рабочую директорию; это значение, по сути, сохраняет информацию о текущей директории в момент запуска команды. Также утилита sudo по умолчанию оставляет в переменной окружения процесса информацию о том, из-под какого пользователя была запущена она сама.
Переменные окружения (и многое другое) для любого запущенного процесса можно посмотреть в /proc. Вуаля:
Кхм, сам и запустил. Ну с кем не бывает.
В общем, вот таким нехитрым методом в простых ситуациях можно найти информацию о процессе, которая в общем случае недоступна.
Скрипт работает из командной строки, но не работает из cron
Одним из случаев, когда приходится вспоминать о переменных окружения, является ситуация, когда добавленный в /etc/crontab скрипт падает с ошибкой. Заходишь на сервер по SSH, запускаешь команду, всё вроде работает как надо. А при автоматическом запуске показывает что-то типа «hive: command not found».
Вообще есть хорошая практика прописывать полный путь до исполняемых команд, однако это не всегда возможно. В таких случаях разработчики выкручиваются кто как может. Кто-то добавляет нужный путь в PATH частью команды в кронтабе. Более опытные оборачивают свою команду в bash -l. А наученные горьким опытом крон-бомбы ещё и flock довернуть не забывают. Всё так: сделал, добавил в мониторинг и забыл.
После таких манипуляций в душе настоящего инженера остаётся некий осадочек. Да, задача решена. Но я же ни фига не понял, что происходит! Чем один подход лучше другого? Где все эти настройки хранятся и кем меняются?
Давайте сравним переменные окружения, которые есть у процесса, когда он запускается из крона, и переменные окружения, которые есть у нас в командной строке. Логируем вывод команды env из крона и своё текущее окружение:
Смотрим, что там в переменной PATH:
Мама мия! Так там под кроном только самый минимум! Конечно же, надо подгружать нормальные переменные окружения.
Давайте посмотрим, какое окружение будет, если добавить bash -l:
Разница уже не так заметна. Все пути представлены. Некоторые в другом порядке, некоторые повторяются, но это уже намного лучше, чем было. Остальные переменные тоже неплохо настроены. Есть, конечно, небольшая разница в локали, в переменных от SSH, но это уже не должно драматично влиять на работу скрипта.
Теперь понятно, почему bash -l просто необходим в crontab-записях. И, конечно же, не забываем про flock.
Отлаживаем инициализацию логин-скриптов
Проблема вроде бы решена, всё из крона работает. Но как же получается, что некоторые пути дублируются в переменной PATH? Значит, есть какой-то беспорядок в настройке сервера. Давайте попробуем разобраться.
Открываем какой-нибудь ман по инициализации окружения, вычитываем, какие скрипты и в каком порядке выполняются, с воодушевлением начинаем пробегать их глазами — и через несколько минут приходит чувство отчаяния. Какой-то бесконечный поток условий про какие-то особые случаи архитектур, терминалов и невероятно важных настроек цветов для команды ls. Боль, отчаяние, ненависть! Нас интересует одна чёртова переменная PATH!
На самом деле всё несколько проще. Знакомьтесь:
Что делает эта команда? Создаёт новый процесс bash с девственно чистым окружением, указывает, что надо запустить скрипты инициализации и всё подробно залогировать в файле login.log. Теперь у нас есть возможность не выполнять в уме все скрипты, а просто прочитать, что, где и когда выполнилось и откуда появилась та или иная настройка окружения.
Я не буду детально разбирать, как читать получившийся лог. Там всё почти тривиально. Упомяну лишь, что одно попадание у меня оказалось из /etc/profile и два — из /etc/bash.bashrc. Да, где-то перемудрили при настройке пакетов в паппете. Ну ничего, мне работать это не мешает.
Зато теперь я знаю и умею!
P. S. В совсем сложных случаях и чтобы разобраться вообще во всём, можно обернуть команду в strace: