Эффективное использование process.env

Подготовка приложения

При работе с переменными окружения в PHP-проекте, вы хотите убедиться, что ваш код всегда будет получать переменную из надежного источника, будь то , , … Но эти три метода не возвращают одинаковые результаты!

$ php -r "echo getenv('HOME');"
/home/foobar

$ php -r 'echo $_ENV;'
PHP Notice: Undefined index: HOME

$ php -r 'echo $_SERVER;'
/home/foobar

Это потому что на моей машине установлена в . И так как в ней нет буквы , я не могу полагаться на суперглобальный массив . Это может привести к тому, что код работающий на одном PHP не будет работать на другом.

Другой камень преткновения – это то, что разработчики не хотят управлять переменными окружения локально. Каждый раз, когда мы редактируем VirtualHost, мы не хотим перезагружать php-fpm или некую службу, или очищать кеш… Разработчики хотят иметь простой и безболезненный способ настройки переменных окружения… как файл!

Файл — это просто сборник переменных окружения с их значениями:

vlucas/phpdotenv, самая популярная библиотека на данный момент:

Эта библиотека будет читать файл и заполнит все суперглобальные переменные:

$dotenv = new Dotenv\Dotenv(__DIR__);
$dotenv->load();

$s3Bucket = getenv('S3_BUCKET');
$s3Bucket = $_ENV;
$s3Bucket = $_SERVER;

Есть несколько хороших плюшек, таких как возможность помечать некоторые переменные, как обязательные. ()

josegonzalez/dotenv, ориентирована на безопасность:

Эта библиотека не заполнит суперглобальные переменные по умолчанию:

$Loader = new josegonzalez\Dotenv\Loader('path/to/.env');
// Парсим файл .env:
$Loader->parse();
// Отправляем результат парсинга .env в переменную $_ENV:
$Loader->toEnv();

Она поддерживает обязательные переменные, фильтрацию, и может выбрасывать исключения, когда переменная перезаписывается.

symfony/dotenv, новый малыш на этом поприще:

Доступен начиная с Symfony 3.3. Этот компонент заботится о -файле, как остальные, и тоже заполняет суперглобальные массивы:

$dotenv = new Symfony\Component\Dotenv\Dotenv();
$dotenv->load(__DIR__.'/.env');

$dbUser = getenv('DB_USER');
$dbUser = $_ENV;
$dbUser = $_SERVER;

На packagist есть ещё куча других и я даже боюсь спрашивать, почему каждый пишет тот же парсер снова и снова.

Но все они используют ту же логику:

• найти файл;
• разобрать его, проверить на вложенные значения, вытащить все переменные;
• заполнить все суперглобальные массивы переменными, кроме тех, что уже установленны.

Я рекомендую комитить файл со значениями, заданными для разработчиков: каждый должен иметь возможность вытащить ваш проект и запустить его так, как ему нравится (сервер из командной строки, Apache, nginx…) без мучений с конфигурацией.

(new Dotenv())->load(__DIR__.'/.env');

Эта рекомендация хорошо работает, когда каждый локально имеет ту же инфраструктуру: тот же пароль к БД, тот же сервер и порт… Т. к. мы используем Docker Compose на всех наших проектах, у нас никогда нет никаких различий в настройках одного разработчика от настроек другого. Если у вас нет такой плюшки, просто позвольте разработчикам перезаписывать настройки по умолчанию, импортировав два файла:

(new Dotenv())->load(__DIR__.'/.env', __DIR__.'/.env.dev');

В этом случае, вы просто должны создать и заполнить файл тем, что отличается для вас (и добавить его ).

Затем на продакшене, вы не должны загружать эти значения по умолчанию:

if (!isset($_SERVER)) {
    (new Dotenv())->load(__DIR__.'/.env', __DIR__.'/.env.dev');
}

Если вы так не сделаете, и ваш хостинг-провайдер забудет передать переменную, то запустите код в продакшене с настройками от дева, а это не приведёт ни к чему хорошему.

A list of the commonly used variables in Linux

set and env command

You can use the env / set command too:

env
env | more
set 
set | more

Sample outputs:

HOME=/home/vivek
vivek@nas01:~$ env
TERM=xterm-256color
SHELL=/bin/bash
XDG_SESSION_COOKIE=9ee90112ba2cb349f07bfe2f00002e46-1381581541.324726-906214463
SSH_CLIENT=192.168.1.6 60190 22
SSH_TTY=/dev/pts/1
USER=vivek
MAIL=/var/mail/vivek
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PWD=/home/vivek
LANG=en_IN
SHLVL=1
HOME=/home/vivek
LANGUAGE=en_IN:en
LOGNAME=vivek
SSH_CONNECTION=192.168.1.6 60190 192.168.1.10 22
_=/usr/bin/env

A note about env/set command

The env will only display a list of environment variables that have been exported and it will not show all bash variables. The set command allows you to change the values of shell options and set the positional parameters, or to display the names and values of shell variables. If no options or arguments are supplied, set displays the names and values of all shell variables and functions, sorted according to the current locale, in a format that may be reused as input for setting or resetting the currently-set variables. Hence, I recommend that you use printenv command to dump the list of all shell variables on screen. To save the list of all shell environment variables to a file, enter:

printenv > env.txt
cat env.txt

Use the grep command to search for particular variable:

printenv | grep foo
printenv | grep HOME

• Bash shell variables from the Linux shell scripting wiki.
• Man pages: env(1)

Logging

Logging is disabled by default in to prevent accidentally logging
secrets.

To enable logging you need to create an instance using the
function that the API provides and pass it a logger. A built-in logger is
available, but a custom logger is also supported.

Always exercise caution when logging environment variables!

The built-in logger will print logs unless is set to either
or .

const{from,logger}=require('env-var')constenv=from(process.env,{}, logger)constAPI_KEY=env.get('API_KEY').required().asString()

Here’s output from the built-in logger that can be seen by running
examples/logging.js included in this repository:

If you’re using a logging solution such as this feature is useful to
filter logs based on log levels, e.g logs can be enabled for trace
logging only.

constpino=require('pino')()constcustomLogger=(varname,str)=>{log.trace(`env-var log (${varname}): ${str}`)}const{from}=require('env-var')constenv=from(process.env,{}, customLogger)constAPI_KEY=env.get('API_KEY').required().asString()

Env vars 101

При запуске программы, она наследует все переменные окружения от своих родителей. Так что если вы установите переменную в значение в bash, а затем выполните команду, вы сможете прочитать в любом дочернем процессе.

$ YOLO=covfefe php -r 'echo getenv("YOLO");'
covfefe

Поскольку эта переменная определена только локально, мы не можем прочитать её из другого терминала (другого родителя). Идея в том, чтобы убедиться, что ваше приложение всегда наследует нужные переменные.

Вы можете посмотреть все переменные окружения в командной строке, выполнив следующую команду, но вы не увидите переменной , т. к. она была передана только в команду «на лету», а не установлена в текущем процессе:

$ env

Вы можете установить переменную окружения с помощью :

Имена переменных чувствительны к регистру и соглашение заключается в использовании имён только на английском, в верхнем регистре, с в качестве разделителя (т. н. «змеиный» стиль в верхнем регистре). Вы уже наверняка знаете некоторые переменные – такие как , , …

Лучшие практики на сегодня

Возможно, вы уже знаете о двенадцати факторной методологии для создания надежных и масштабируемых приложений (если нет, то я предлагаю вам сделать перерыв и проверить его). Глава о конфигурации объясняет, почему сохранение конфигов в окружении это правильный путь:

• Конфигурация существенно отличается в зависимости от того, где развёрнуто приложение (production, staging, testing…), код – нет.
• Переменные окружения легко изменять на разных машинах без изменения кода.
• Они являются стандартом и не зависят от используемого язык или ОС. Одни и же конфигурации могут использоваться и PHP, и Python процессами.

Манифест также довольно хорошо описывает что должно быть в коде и что должно быть в окружении – не кладите все настройки приложения в него, только то, что отличается у одного развернутого стенда от другого.

Config

constresult=dotenv.config()if(result.error){throwresult.error}console.log(result.parsed)

You can additionally, pass options to .

Default:

You may specify a custom path if your file containing environment variables is located elsewhere.

require('dotenv').config({ path'/full/custom/path/to/your/env/vars'})

Default:

You may specify the encoding of your file containing environment variables.

require('dotenv').config({ encoding'latin1'})

Default:

You may turn on logging to help debug why certain keys or values are not being set as you expect.

require('dotenv').config({ debugprocess.env.DEBUG})

Usage

constenv=require('get-env')();

This returns either or . (pre-registered environments)

Extra environments can be optionally added in addition to the pre-registered environments ( and ) with any of the following methods:

constenv=require('get-env')('test');

• Return when the value is .
• Otherwise, return or . (default rules apply)

constenv=require('get-env')('docker','test');constenv=require('get-env')('docker','test');

• Return when the value is .
• Return when the value is .
• Otherwise, return or . (default rules apply)

constenv=require('get-env')({  docker'docker',  test'test','testing',  prod'pr','prod','production'});

• Return when the value is .
• Return when the value is or .
• Return when the value is , , or . (pre-reigstered rules for are overriden)
• Otherwise, return .

Зачем нужна виртуальная среда?

Python, как и большая часть других современных языков программирования, имеет собственный, уникальный способ загрузки, хранения и разрешения пакетов (или модулей). Это имеет свои преимущества, однако были принятые некоторые интересные решения, на счет хранения и разрешения пакетов, которые привели к определенным проблемам, а именно: как и где эти пакеты хранятся?

Существует несколько разных расположений, в которых хранятся пакеты, которые можно установить в вашей системе. Например, большая часть системных пакетов хранятся в дочернем каталоге пути, который, в свою очередь, хранится в sys.prefix.

На Mac OS X, вы можете легко найти, где именно sys.prefix указывает на использование оболочки Python:

Python

import sys
print(sys.prefix) # ‘/System/Library/Frameworks/Python.framework/Versions/3.5’

Python

import site
data = site.getsitepackages()

print(data)

Результат:

Python

[
‘/System/Library/Frameworks/Python.framework/Versions/3.5/Extras/lib/python’,
‘/Library/Python/3.5/site-packages’
]

Виды переменных окружения

Вам будет интересно:Как проверить версию Windows 10: несколько простейших методов

Согласно методу объявления и способам инициализации переменные окружения Linux могут быть трех различных видов:

Локальный тип переменных и констант инициализируется во время запуска системы и после выхода удаляется встроенным деконструктором. Удаление данного вида данных произойдет в любом случае, вне зависимости от того, как произведено подключение к аппаратному обеспечению: через устройства удаленного доступа, эмуляцию терминала или создание сессии через виртуальную машину. Во время обработки они не сохраняются ни в одном из файлов или директорий. Создание и деконструкция переменных происходит за счет специализированных команд в оболочке управления.
Пользовательские переменные окружения Linux инициализируются для каждого из пользователей операционной системы. Определение и загрузка происходит во время входа в операционную систему. Так же как и с другими видами, вне зависимости от входа через локальный терминал либо удаленного доступа, определение происходит автоматически. Сохранение данных обеспечивается в документах, которые отвечают за конфигурацию устройства. Также возможно хранить их в других документах, размещающихся в пользовательских папках. Чаще всего находятся в файлах bash_profile, bash_login и других конфигурационных файлах.
Системные. Данный вид доступен при работе системы каждому пользователю. Применяются для управления системными функциями и требуются для корректной работы операционной системы. Загрузка осуществляется из директории с системными файлами окружения, профиля, etc / environment и многих других.

Relation Between Parent Shell and Child Shells

When dealing with environment variables, we need to be aware of some points concerning the shell hierarchy of parent shell, child shell, child of child shell, and so on:

Syntax

exec [-c] [-l] [-a name] [command [arguments ...]] [redirection ...]

Options and arguments

The exec builtin command takes the following options and arguments:

Description

exec is useful when you want to run a command, but you don’t want a bash shell to be the parent process. When you exec a command, it replaces bash entirely — no new process is forked, no new PID is created, and all memory controlled by bash is destroyed and overwritten. This can be useful if, for instance, you want to give a user restricted access to a certain command. If the command exits because of an error, the user will not be returned to the privileged shell that executed it.

exec may also be used without any command, to redirect all output of the current shell to a file. For more information about redirection, see .

Parse

The engine which parses the contents of your file containing environment
variables is available to use. It accepts a String or Buffer and will return
an Object with the parsed keys and values.

constdotenv=require('dotenv')constbuf=Buffer.from('BASIC=basic')constconfig=dotenv.parse(buf)console.log(typeof config, config)

Default:

You may turn on logging to help debug why certain keys or values are not being set as you expect.

constdotenv=require('dotenv')constbuf=Buffer.from('hello world')constopt={ debugtrue}constconfig=dotenv.parse(buf, opt)

The parsing engine currently supports the following rules:

• becomes
• empty lines are skipped
• lines beginning with are treated as comments
• empty values become empty strings ( becomes )
• inner quotes are maintained (think JSON) ( becomes )
• single and double quoted values are escaped ( becomes )
• single and double quoted values maintain whitespace from both ends ( becomes )
• double quoted values expand new lines ( becomes

Команда env

Команда env позволяет модифицировать список переменных окружения перед исполнением пользовательской команды. В некоторых командных оболочках она является встроенной, в некоторых — внешней командой.

Базовый синтаксис команды выглядит следующим образом:

При вызове env без каких-либо параметров будет выведен список всех переменных окружения. В качестве команды может использоваться произвольная команда с любыми аргументами или без аргументов, для корректного исполнения которой требуется изменение значений переменных окружения. Наиболее часто используемыми параметрами являются параметр -i, позволяющий игнорировать все системные переменные окружения и параметр -u, после которого должно идти имя переменной окружения, которую нужно игнорировать.

Наиболее часто используемыми переменными окружения являются переменные со следующими именами:

Обозначение системного часового пояса

Рассматриваемая команда особенно полезна для написания переносимых сценариев командной оболочки, так как она позволяет полностью отказаться от сохранения полного пути к бинарному файлу интерпретатора сценариев после последовательности шебанг (!#). Это полезная практика, так как в одной системе бинарный файл интерпретатора может располагаться в директории /usr/bin, в другой — в директории /usr/local/bin, а в третьей — вообще в директории /opt. Известно, что после последовательности шебанг должен располагаться полный путь к бинарному файлу интерпретатора, но вы также можете разместить после нее полный путь к бинарному файлу утилиты env, которая будет использоваться для получения пути к бинарному файлу интерпретатора. Исходя из этого, вы можете использовать в качестве аргумента рассматриваемой утилиты лишь имя бинарного файла нужного интерпретатора, например, bash:

после чего будет осуществляться автоматический поиск этого бинарного файла директориях поиска (перечисленных в значении переменной PATH) с его последующим запуском, причем все строки после последовательности шебанг будут переданы запущенному интерпретатору.

Примеры использования

Вывод значений всех переменных окружения

Для ознакомления со всеми значениями переменных окружения достаточно выполнить команду env без каких-либо аргументов:

Исполнение команды с измененными значениями переменных окружения

Для изменения значения произвольной переменной окружения перед запуском команды достаточно указать имя этой переменной и ее значение после символа равенства. Например, для вывода времени по Гринвичу достаточно изменить значение переменной окружения TZ:

Исполнение команды лишь с заданными переменными окружения

Для исполнения команды с несколькими пользовательскими переменными окружения следует воспользоваться параметром -i и вручную задать значения необходимых переменных:

FAQ

No. We strongly recommend against committing your file to version
control. It should only include environment-specific values such as database
passwords or API keys. Your production database should have a different
password than your development database.

No. We strongly recommend against having a «main» file and an «environment» file like . Your config should vary between deploys, and you should not be sharing values between environments.

We will never modify any environment variables that have already been set. In particular, if there is a variable in your file which collides with one that already exists in your environment, then that variable will be skipped. This behavior allows you to override all configurations with a machine-specific environment, although it is not recommended.

If you want to override you can do something like this:

constfs=require('fs')constdotenv=require('dotenv')constenvConfig=dotenv.parse(fs.readFileSync('.env.override'))for(constkin envConfig){process.envk= envConfigk}

For : Yes. now returns an object representing
the parsed file. This gives you everything you need to continue
setting values on . For example:

constdotenv=require('dotenv')constvariableExpansion=require('dotenv-expand')constmyEnv=dotenv.config()variableExpansion(myEnv)

ES2015 and beyond offers modules that allow you to any top-level , , , , or .

You must run before referencing any environment variables. Here’s an example of problematic code:

import{Client}from'best-error-reporting-service'exportconstclient=newClient(process.env.BEST_API_KEY)

importdotenvfrom'dotenv'importerrorReporterfrom'./errorReporter'dotenv.config()errorReporter.client.report(newError('faq example'))

will not be configured correctly because it was constructed before was executed. There are (at least) 3 ways to make this work.

1. Preload dotenv: (Note: you do not need to dotenv with this approach)
2. Import instead of (Note: you do not need to call and must pass options via the command line or environment variables with this approach)

Conclusion

I just made my Linux/Unix script portable with #!/usr/bin/env. The env-mechanism is hugely enhancing convenience, and almost all Unix like systems today provide /usr/bin/env. I regular use FreeBSD, CentOS/RHEL/Ubuntu/Debian/SUSE Linux, macOS, and OpenBSD and all of them provided /usr/bin/env by default. Now you do not have to search for a program via the PATH environment variable. It makes the script more portable. Also, note that it is not a foolproof method. Always make sure you have /usr/bin/env exists or use a soft link/symbolic link to point it to correct path for env command. Moreover, your work or script looks more professional with this simple hack. See env command man page (documentation) or type the following man command:

Время переменных окружения

Мы можем хранить секретные данные, настройки сборки и другие данные в переменных окружения. Программа на nodejs имеет к ним доступ.

В nodejs есть глобальный объект process (доступный из любого места программы, как window в браузере), хранящий информацию о текущем процессе. У этого объекта есть свойство env — оно и дает доступ к переменным окружения. Попробуйте запустить node в терминале и выполнить console.log(process.env):

https://gist.github.com/Hydrock/91d18e8c57a9572d07ac12c39de1056c

Мы увидим как в терминал выведется объект со всеми значениями переменных окружения.

Теперь если представить, что наш секретный ключ уже находится в переменных окружения, то предыдущий пример можно переписать так:

https://gist.github.com/Hydrock/b5ab3530bb20a2d85d2483bc84603dc3

Мы получаем наш секретный ключ из окружения. Отличный пример .

Еще, вы наверняка использовали или встречали конструкцию node.env.NODE_ENV === ‘production’ для определения режима сборки своего приложения.

Но как же установить эти переменные окружения?

4.6 Переменные Bash.

Эти переменные задаются и используются Bash, но в других оболочках
обычно специально не рассматриваются.

HISTCONTROL

history_control

При присвоении значения ‘ignorespace’ строки, начинающиеся с
пробела или табуляции, не вводятся в список истории. При присвоении значения ‘ignoredups’ строка, соответствующая прошлой
введенной строке, не вводится. ‘ignoreboth’ сочетает эти две
опции. Присвоение любого другого значения обозначает сохранение всех строк в списке «истории».

HISTFILE

Имя файла, хранящего команду истории.

HISTSIZE

Если задана, это максимальное число команд, которые должны быть
запомнены в истории.

histchars

Восходит к трем символам, контролирующим расширение истории,
быстрое замещение и лексемизацию (см. раздел 6.1 «Диалог истории»). Первый символ — символ расширения истории, обозначающий
начало расширения истории — обычно ‘!’. Второй обозначает быструю замену при нахождении первого символа на строке, обычно
‘^’. Опционный третий символ помечает остаток строки — комментарий, когда он найден как первый символ слова, обычно ‘#’.
Символ комментария истории вызывает замену истории, игнорируемую для оставшихся слов на строке. Не обязательно вызывает синтаксический разбор оболочки для рассмотрения остатка строки как
комментария.

HISTCMD

Номер истории или индекс списка истории текущей команды. Если
HISTCMD не задана, она теряет свои специальные свойства, даже
если впоследствии она опять задается.

hostname_completion_file

HOSTFILE

Содержит имя файла в том же формате, что и ‘/etc/hosts’, которое должно считываться, когда оболочке нужно завершить
hostname. Вы можете иэменить файл в диалоговом режиме. В следующий раз, когда вы попытаетесь завершить hostname, Bash добавит содержание файла к уже существующей базе данных.

MAILCHECK

Показывает, как часто (в секундах) оболочка должна проверять
файлы, указанные в MAILPATH, на наличие почты.

PROMPT_COMMAND

Если есть, содержит строку с командой для выполнения перед выводом каждой базовой команды приглашения ($PS1).

UID

Числовой идентификатор реального пользователя для текущего
пользователя.

ЕUID

Числовой идентификатор зффективного пользователя для текущего
пользователя.

HOSTTYPE

Строка, описывающая машину, на которой запущен Bash.

OSTYPE

Cтрока, описывающая операционную систему, в которой запущен
Bash.

FIGNORE

Разделенный двоеточиями список суффиксов, игнорируемых при завершении имени файла. Имя файла, чей суффикс соответствует одному из приведенных в FIGNORE, извлекается из списка соответствующих имен файлов. Образцовое значение — ‘.o:~’.

INPUTRC

Имя файла начальных действий Readline, заменяемое по умолчанию
на ‘~/.inputrc’.

BASH_VERSION

Имя версии текущего зкземпляра Bash.

IGNOREEOF

Контролирует получение символа EOF оболочкой в отдельном вводе.
Если задана, то ее значение — число последовательных символов
EOF, которые могут быть считаны как первые символы строки ввода перед выходом из оболочки. Если переменная существует, но не
имеет числового значения, то по умолчанию зто 10. Если переменная не существует, EOF отмечает конец ввода в оболочку. Действует только в диалоговых оболочках.

no_exit_on_failed_exec

Если эта переменная существует, то оболочка не выходит, если
она не может выполнить файл, указанный в команде exec.

nolinks

Если есть, говорит о том, что не нужно следовать символическим
указателям в командах, изменяющих текущий рабочий каталог. По
умолчанию Bash следует по логической цепи каталогов при выполнении команд таких как cd, изменяющая рабочий каталог.
Например, если ‘/usr/sys/’ — указатель на ‘/usr/local/sys’, то:

Если nolinks существует, то:

См. также описание опции -p встроенной команды set, раздел 4.5.

Подводные камни, на которые вы должны обратить внимание ⚠

Конфликты имен

Нейминг – это сложно, и переменные окружения не являются исключением из этого правила.

Поэтому при именовании переменных окружения, вы должны быть осторожными и допускать как можно меньше конфликтов имен. Ситуация усложняется тем, что нет официального списка зарезервированных имен. Хорошая практика – использовать префиксы пользовательских переменных.

В мире Unix это уже делают, используя , , …

Отсутствие переменных во время выполнения

У вас есть два варианта в случае, если переменная отсутствует: либо бросить исключение, или использовать значение по умолчанию. Решать вам, но второй вариант молчаливый… Что может принести вред во многих случаях.

Как только вы захотите использовать переменные окружения, вы должны установить их везде:

• на веб-сервере;
• в длительных скриптах и сервисах;
• в crontab-ах…
• и в сценарии развертывания!

Про последний легко забыть, но так как сценарии могут разогревать кеш приложения (как Symfony-вские)… да, отсутствие переменной может привести к поломке деплоя. Будьте осторожны с этим и добавите проверку при запуске приложения.

Префикс

Есть только один префикс, который вы никогда не должны использовать: . Потому что его использует сам PHP (и другие cgi-подобные контексты) для хранения заголовков http-запроса.

Вы помните httpoxy уязвимость? Она возникала при поиске http-клиентом переменной в окружении таким образом, что её можно было установить через простой http-заголовок.

Некоторые DotEnv-библиотеки также предотвращают переопределение таких переменных, например, -компонент.

Потокобезопасность функции getenv()

У меня плохие новости: в некоторых конфигурациях, использование функции приведет к неожиданным результатам. Эта функция не потокобезопасна!

Вы не должны использовать её для получения ваших значений, поэтому я предлагаю вам вместо этого обращаться к – к тому же есть небольшая разница в производительности между обращением к массиву и вызовом функции в пользу массивов.

Переменные окружения – всегда строки

Одной из главных проблем является то, что сейчас в PHP есть указание типов, а наши настройки не всегда правильно набраны.

class Db
{
    public function connect(string hostname, int port)
    {
    }
}

// Это не будет работать:
$db->connect($_SERVER, $_SERVER); 

В Symfony теперь можно преобразовывать variables, а даже больше – чтение файла, декодирование json……

Examples

The following series of commands will illustrate how variables are passed to a child process in bash, with and without export. First, set the value of a new variable named myvar:

myvar="This variable is defined."

Verify that it has been set, and that it has a value in the current shell context:

echo $myvar

This variable is defined.

Create a new shell context by running bash at the bash command prompt:

bash

Now you have a new bash shell, which is running inside your original bash session. The variable myvar has no value in this context, because it was not passed from the original shell:

echo $myvar

(Only a newline is printed, because myvar has no value.)

Now, exit this shell, which will return you the original bash session:

exit

Here, myvar still has a value:

echo $myvar

This variable is defined.

Now, start a new bash session again — but this time, export the variable first:

export myvar

bash

This time, the value of myvar has been passed to the new shell:

echo $myvar

This variable is defined.

Great. Exit the subshell:

exit

Now let’s verify that it works with functions, too.

Create a new shell function, myfunc. You can define a bash shell function by placing parentheses after the function name, and then a . A compound command can take different forms; here, we will enclose it in curly braces, with a semicolon after each command, including the last one:

myfunc () { echo "This function is defined."; }

Now myfunc is a command name that you can run in the current shell:

myfunc

This function is defined.

To pass this function to any child processes, use export -f:

export -f myfunc

You can verify that it is passed by starting bash in a child process, and running myfunc:

bash

myfunc

This function is defined.

Hopefully these examples help you better understand how export is useful, and give you a better understanding of how bash creates new processes.

Don’t forget that you can always check which variables and functions will be exported to child processes by running export -p:

export -p

(a really long list of what gets exported from the current shell)