источник по сравнению с экспортом по сравнению с LD_LIBRARY_PATH экспорта
При компиляции приложений от использования исходного кода make или cmake в инструкциях обычно говорится,
source <some path> <parameter>
export <some text>
Кроме того, много времени LD_LIBRARY_PATH подходит, используясь с export.
Из чего различие source и export ? Почему нам нужны они?
1 ответ
Команды оболочки source и export действительно разные вещи. Короче говоря:
source
Когда Вы будете звонить, сценарий оболочки нормальный путь (скажите с ./myscript.sh или sh myscript.sh), это будет выполняться в его собственном контексте процесса (новая среда процесса), таким образом, весь набор переменных в сценарии не будет доступен в оболочке вызова. При выполнении сценария с помощью source команда, это будет выполняться в контексте сценария выполнения вызова. Таким образом, Вы можете установить переменные среды путем вызова source myscript.
export
Переменные среды обычно только допустимы в (локальном) контексте текущего процесса. Так, при выполнении чего-то (сценарий или программа), который запрашивает новую среду процесса, окружение не будет замечено в рамках нового процесса. Для передачи значений среды дочернему процессу необходимо 'экспортировать' их путем предшествования присвоению с export, например. export VAR=value.
export LD_LIBRARY_PATH
Специальная переменная среды LD_LIBRARY_PATH определяет путь, где загружаемые библиотеки разыскиваются (подобный PATHпеременная, которая определяет, где искать исполняемые файлы). Библиотеками по умолчанию ищутся в /lib, /usr/lib и т.п.. Библиотеки установлены в нестандартных каталогах (например. /opt/program/lib) может только быть загружен, когда эти пути дополнительно определяются export LD_LIBRARY_PATH=/opt/program/lib в этом примере. Вы должны экспортировать сюда, как это должно быть известно новой среде процесса, Ваша программа работает в.
Персистентность
Среда процесса существует, пока процесс работает; это также сохраняется для переменных среды (если не сброс явно). Если процесс будет уничтожен (например, путем закрытия окна терминала), то обычно все подпроцессы будут уничтожены также, и среда (среды) удалены. Более точно это зависит от того, как дочерний процесс воздействует SIGHUP. Если это не сделает, то это будет работать далее как ребенок пользовательского процесса (например. /sbin/upstart --user) или процесс init (PID=1).
Один способ иметь подпроцессы преодолевает уничтожение родительского процесса, должен выпустить их от родительского процесса при помощи nohup команда (см. man nohup), который не передаст SIGHUP ребенку и выпуску процесса к фону:
nohup <progname> &
отсоединит процесс от родителя, присвоит STDIN /dev/null и STDOUT к ./nohup.out.