Утилита env нужна для просмотра текущих переменных окружения и/или запуска программ в специфическом окружении. Будучи вызвана без аргументов она печатает список текущих переменных и их значения. Можно задать команде env список переменных и их значения и команду. Тогда эта команда будет выполнена с указанными переменными. Опция -i может применяться для того, чтобы env(1) не наследовала уже заданных переменных. Чтобы узнать значение конкретной переменной можно так же использовать команду printenv(1). Например:

$ env | grep TZ
TZ=Europe/Moscow
$ date
среда, 15 февраля 2006 г. 22:14:28 (MSK)
$ env TZ=Asia/Irkutsk date
четверг, 16 февраля 2006 г. 03:14:38 (IRKT)
$ date
среда, 15 февраля 2006 г. 22:14:41 (MSK)
$ printenv TZ
Europe/Moscow
          

Есть распространённая практика писать утилиту env(1) в «магичекую строку» (shebang), с которой обычно начинаются сценарии:

#!/usr/bin/env python
          

Таким способом программисты страхуются от того, что интерпретатор python(1) может находиться в неправильном месте. Так, в FreeBSD, DragonFly BSD и OpenBSD python(1) будет скорее всего установлен в каталог /usr/local/bin, в NetBSD в /usr/pkg/bin, в Linux он возможно будет стоять в /usr/bin. Чтобы магическая строка всегда работала нужно либо переписывать её при инсталляции скрипта (Обычно инсталляторы так и желают), либо писать как выше в расчёте на то, что путь к языку python(1) у пользователя прописан в переменной PATH.

Такой подход по ряду причин надо признать крайне неудачным. Во-первых, такой скрипт будет работать не всегда. Будучи вызван из crontab он может работать в ситуации, когда переменная PATH вообще не задана. Кроме того, влияя на переменную PATH пользователь может подсунуть поддельный интерпретатор. Если вы выдали недобросовесному судоеру права на запуск утилиты /root/bin/util.py с правами root, а в утилите в магической строке python(1) вызывается через env(1), то судоер может переопределив PATH подсунуть поддельный python и получить полный контроль над системой.

С другой стороны, прежде чем выдавать права суперпользователя на исполнения некоторого скрипта, надо хорошо понимать как работает интерпретатор, который вы используете. Рассмотрим пример с тем же python(1). Пусть у нас есть скрипт hello.py такого содержания:

#!/usr/local/bin/python
print "Hello World!"
          

Запустив этот скрипт командой

$ sudo env PYTHONINSPECT="1" ./test.py
Hello World
>>>
          

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

#!/usr/local/bin/python
import sys
print "Hello World!"
sys.exit()
          

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

#!/usr/bin/env -i /usr/local/bin/python
print "Hello World!"
          

В интерпретаторе sh можно задать значение переменной путём присваивания: var=value, например NEW=1. После этого переменную можно использовать, на её значение можно ссылаться из по имени $NEW, но она ещё не стала переменной окружения. Чтобы эта переменная стала видна программе как переменная окружения, её надо экспортировать командой export.

$ NEW=1
$ echo $NEW
1
$ printenv NEW
$ export NEW
$ printenv NEW
1
          

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

Полный список переменных можно узнать командой set без аргументов, а список экспортированных переменных командой export без аргументов.