Shell как язык программирования и интегратор

Профили

Допустим, мы написали некоторый командный сценарий, настраивающий сообразно нашему вкусу окружение shell. Этот сценарий можно "втянуть" при помощи команды " ." (см. выше). Было бы неплохо, если бы каждый раз при входе в систему shell обрабатывал этот сценарий, не дожидаясь команды. Поскольку задача эта, во-первых, хорошо автоматизируется, а во-вторых, упрощает взаимодействие с системой, она, скорее всего, уже решена.

Когда при входе в систему login запускает командный интерпретатор, тому в качестве нулевого параметра (имя самой программы) передается, скажем, не sh, а -sh. В результате shell начинает вести себя особенным образом, как стартовый командный интерпретатор (т. н. login shell ). В частности, он считывает и выполняет специальный сценарий, называемый общий профиль (для командных интерпретаторов гнезда Bourne - это файл /etc/profile ) и собственный профиль пользователя (для sh это файл $HOME/.profile ), в который и стоит вписывать свои изменения в настройке окружения ( командные интерпретаторы семейства C пользуются /etc/csh.login и .login соответственно).

Современные оболочки идут в этом плане гораздо дальше стандартного sh. Вот, например, описание того, как устроены входные и выходные сценарии zsh. По аналогии со стандартным профилем, каждый из этих файлов бывает общим (обычно находится в /etc ) или личным (находится в домашнем каталоге пользователя, имя файла начинается на " ."). Сначала любой запущенный zsh выполняет общий, а затем - личный файл zshenv. Потом, если командный интерпретатор - стартовый, выполняется общий и личный профили ( zprofile, а за неимением такового - profile ). Далее, если командный интерпретатор - интерактивный (запущен для диалога с пользователем, а не для выполнения сценария ), выполняется общий и личный zshrc. Наконец, стартовый zsh выполняет общий и личный файлы zlogin (в нем можно пользоваться определенными в .zshrc функциями и сокращениями). По окончании сеанса работы пользователя, при завершении стартового zsh, выполнится сначала личный, а затем - общий zlogout.

И на дуде игрец

В чем еще современные оболочки опережают старый добрый /bin/sh?

Многие полезные и часто используемые команды ( test, echo, kill, wait и т. п.) в современных shell делают встроенными (built-in): это весьма увеличивает быстродействие и разгружает систему, потому что встроенные команды - подпрограммы shell - не требуют ресурсоемких системных операций с процессами и переключения контекста процесса.

Во многих shell есть массивы, а в zsh предусмотрена поддержка ассоциативных массивов (по сути дела, индексированных списков). Использование ассоциативных массивов очень удобно при обработке текстов, но требует изрядного усложнения синтаксиса языка, в частности в плане подстановки значений.

С подстановкой значений переменных (variable expansion) в zsh творится вообще непонятно что. Включая в язык разнообразные модификаторы, позволяющие по ходу подстановки отрезать части содержимого переменной, заменять некоторые символы другими, превращать подстановку в несколько слов, выравнивать по ширине и т. д., разработчики zsh напрочь забывают об У! Мы насчитали более 50 (!) таких модификаторов, так что всякий раз, когда хочется ими воспользоваться, нужно заглядывать в руководство. Единственное, чего авторы zsh этим достигли, - вместо вызова специализированной внешней программы, вроде sed или awk, можно воспользоваться вложенными подстановками. Сценарии и вправду работают быстрее, но следует помнить, что командный интерпретатор, в отличие от названных утилит, не предназначен для обработки текстов!

Многие shell толкуют содержимое PS1 на свой лад. Впереди опять-таки zsh, в котором определено даже нечто вроде условного оператора внутри PS1 (используется для урезания длины подсказки).

Перенаправление ввода/вывода тоже со временем обогащается удобными сокращениями. Например, часто вместо > файл 2>&1 вводится операция >& файл, а в zsh есть еще и |&, заталкивающая оба потока вывода (стандартный и ошибки) в канал.

И наконец, по мере усложнения и распространения командного интерпретатора нарастает неоднозначность толкования некоторых его конструкций. Точнее, ширится и круг желающих, чтобы нечто работало "так", и круг желающих, чтобы оно работало "эдак". Например, что делать с шаблоном ' a* ', если файлов, начинающихся на " a ", вообще нет? Выдавать ошибку или передавать строку ' a* ' команде? В tcsh и bash подобные вопросы решались с помощью ключей самого shell, и в zsh тоже, но в нем-то таких неоднозначностей более сотни! Так что от ключей пришлось отказаться. Вместо этого для каждого модификатора поведения придумали осмысленное собственное имя и ввели команду setopt.