Упорядочивание стилей работы
Постепенно различия между клонами становились все более значительными. Во-первых, в основе существовавших вариантов Unix лежали разные базовые системы - SVR3, SVR4, 4BSD. Во-вторых, каждый разработчик считал своим долгом либо адаптировать систему под возможности собственной аппаратной платформы, либо просто внести те или иные усовершенствования. А поскольку практически все существовавшие системы были не только проприетарными, но и закрытыми, усовершенствования эти слабо согласовывались между собой. И, в любом случае, реализовывались различным образом.
Это ставило под угрозу один из краеугольных камней Unix-идеологии - портируемость приложений. А традиции писать программы под абстрактный Unix никто не отменял. И начался процесс, который, вслед за товарищем Мао, можно назвать "борьбой за упорядочивание трех стилей работы". Однако председателю КПК было попроще - в данном случае речь шла не о трех, а едва ли не о тридцати трех стилях...
Тем не менее, процесс упорядочивания пошел. Первый шаг в этом направлении резонно было бы сделать основоположнику Unix. И AT&T создала документ, описывающий спецификации, которым должна соответствовать система, претендующая на звание Unix - SVID (System V Interface Definition, то есть определение интерфейса System V). И даже разработала программу, которая проверяла претендента на соответствие этим спецификациям - System V Verification Suite.
Нетрудно было предположить, что в этих спецификациях нашли отражение только те особенности BSD, которые были инкорпорированы в каноническую System V. А ведь BSD была столь же полноводным источником, из которого черпали все производители Unix. Их такое положение дел не очень устроило. И потому было создано несколько организаций, разрабатывающих свои версии стандартов для операционных систем, расширенные по сравнению со SVID. Наибольшее признание из таких разработок заслужил стандарт POSIX (Portable Operation System Interface based on uniX).
Набор соглашений POSIX был разработан международной организацией под названием IEEE.
Термин Portable в названии первоначально означал, что соответствующая POSIX-спецификациям система может быть перенесена (возможно, с минимальными модификациями) на любое компьютерное "железо". То есть - на машины с любой архитектурой - ведь тогда ОС Unix-семейства функционировали не только (точнее даже, не столько) на PC. Однако со временем не менее важным оказался несколько другой аспект этого термина: любая прикладная программа, написанная в соответствии со стандартами POSIX, теоретически может быть перенесена (подчас без всяких переделок) на любую ОС POSIX-совместимого семейства. И нужно отметить - это один из тех редких случаев, когда теоретические ожидания блестяще подтвердились практикой.
Стандарты POSIX существуют в виде серии регулярно обновляемых документов (общим числом под два десятка), в которых описываются спецификации отдельных компонентов систем. Из них наибольший интерес для нас представляет документ IEEE Std 1003.1, в последней редакции которого (от 2004 г. - 2004 Edition) были объединены ранее отдельные стандарты. В современном своем виде он включает четыре "тома":
Важно понимать, что стандарты POSIX жестко определяют базовую функциональность систем и приложений. Каковая, ради потери совместимости, и не должна изменяться. В то же время расширению функциональности они отнюдь не препятствуют. Так, любая из предусмотренных для POSIX-систем команда должна иметь определенный набор опций, предназначенных для выполнения базового набора действий.
Однако никто не препятствует введению для данной команды дополнительных возможностей, реализуемых через опции, стандартом не предусмотренные. Важно только, чтобы первозданная функциональность команды оставалась неприкосновенной.
Я понятно выразился в предыдущем абзаце? Если не очень, попробую пояснить на паре конкретных примеров. Так, в стандарте POSIX предусмотрена команда split, предназначенная для разделения текстового файла на отдельные фрагменты - по размеру (в байтах, килобайтах или мегабайтах) или числу строк. Что достигается указанием соответствующих опций, также описанных в стандарте (-b и -l, соответственно). И именно это команда split обязана делать в любой системе, претендующей на звание POSIX-совместимой.
И, скажем, реализация команды split в Linux (вернее, в пакете coreutils проекта GNU - одном из компонентов Base Linux) выполняет свои обязанности буквально. А вот та же команда в BSD-реализации делает все то же, но имеет еще и дополнительную возможность - разбиение текста на фрагменты по шаблонам (например, заголовкам вида Глава или Часть). Для чего в ней введена опция -p (или --pattern), выходящая за рамки стандарта.
Еще более показательный пример расширения заложенных в стандарте возможностей при полном сохранении базовой функциональности, - это командные оболочки.
В стандарте POSIX предусмотрено, что стандартная (пардон за тавтологию) оболочка POSIX-совместимых систем (еще раз прошу прощения) должна носить имя sh, располагаться в каталоге /bin корня файловой системы и выполнять совершенно определенный набор действий. Каковой, однако, показался многим разработчикам явно недостаточным, в результате чего были придуманы POSIX-совместимые оболочки bash и zsh, умеющие делать все то же, что и POSIX-shell, плюс многое (bash) или очень многое (zsh) другое.
Именно на стандарты POSIX в первую очередь и опирался Линус Торвальдс, создавая свою ОС по мотивам MINIX. Однако это уже следующая история.
