Сценарии командной оболочки. Linux, OS X и Unix. 2-е издание - [8]
Что такое POSIX?
В первые дни Unix был сродни Дикому Западу: разные компании создавали новые версии операционной системы и развивали их в разных направлениях, одновременно уверяя клиентов, что все эти новые версии — просто разновидности Unix, совместимые между собой. Но в дело вмешался Институт инженеров электротехники и электроники (Institute for Electrical and Electronic Engineers, IEEE) и, объединив усилия всех основных производителей, разработал стандартное определение Unix под названием «Интерфейс переносимой операционной системы» (Portable Operating System Interface, или POSIX), которому должны были соответствовать все коммерческие и открытые реализации Unix. Нельзя купить операционную систему POSIX как таковую, но все доступные версии Unix и GNU/Linux в общих чертах соответствуют требованиям POSIX (хотя некоторые ставят под сомнение необходимость стандарта POSIX, когда GNU/Linux сам стал стандартом де-факто).
Однако иногда даже POSIX-совместимые реализации Unix отличаются друг от друга. В качестве примера можно привести команду echo, о которой рассказывается далее в этой главе. Отдельные версии этой команды поддерживают флаг −n, который запрещает добавлять символ перевода строки по умолчанию. Другие версии echo поддерживают экранированную последовательность \c, которая интерпретируется как «не включать перевод строки», а третьи вообще не дают возможности запретить добавление этого символа в конце вывода. Более того, отдельные системы Unix имеют командные оболочки, где команда echo реализована как встроенная функция, которая игнорирует флаги −n и \c, а также включают стандартную реализацию команды в виде двоичного файла /bin/echo, обрабатывающую эти флаги. В результате возникают сложности со сценариями запросов на ввод данных, потому что сценарии должны работать одинаково в как можно большем количестве версий Unix. Следовательно, для нормальной работы сценариев важно нормализовать поведение команды echo, чтобы оно было единообразным в разных системах. Далее в этой главе, в сценарии № 8, вы увидите, как заключить команду echo в сценарий командной оболочки, чтобы получить такую нормализованную версию.
Некоторые сценарии в этой книге используют дополнительные возможности bash, поддерживаемые не всеми POSIX-совместимыми командными оболочками.
Но хватит теории — приступим к знакомству со сценариями, которые будут включены в нашу библиотеку!
№ 1. Поиск программ в PATH
Сценарии, использующие переменные окружения (такие как MAILER или PAGER), таят в себе скрытую опасность: некоторые их настройки могут ссылаться на несуществующие программы. Для тех, кто не сталкивался прежде с этими переменными окружения, отметим, что MAILER должна хранить путь к программе электронной почты (например, /usr/bin/mailx), а PAGER должна ссылаться на программу постраничного просмотра длинных документов. Например, если вы решите увеличить гибкость сценария и вместо системной программы постраничного просмотра по умолчанию (обычно more или less) использовать для отображения вывода сценария переменную PAGER, необходимо убедиться, что эта переменная содержит действительный путь к существующей программе.
Этот первый сценарий показывает, как проверить доступность указанной программы в списке путей PATH. Он также послужит отличной демонстрацией нескольких приемов программирования на языке командной оболочки, включая определение функций и переменных. Листинг 1.1 показывает, как проверить допустимость путей к файлам.
Код
Листинг 1.1. Сценарий inpath с определениями функций
>#!/bin/bash
># inpath — Проверяет допустимость пути к указанной программе
># или ее доступность в каталогах из списка PATH
>in_path()
>{
>··# Получает команду и путь, пытается отыскать команду. Возвращает 0, если
>··#·· команда найдена и является выполняемым файлом; 1 — если нет. Обратите
>··#·· внимание, что эта функция временно изменяет переменную окружения
>··#·· IFS (Internal Field Separator — внутренний разделитель полей), но
>··#·· восстанавливает ее перед завершением.
>··cmd=$1········ourpath=$2···· result=1
>··oldIFS=$IFS·· IFS=":"
>··for directory in "$ourpath"
>··do
>····if [-x $directory/$cmd]; then
>······result=0······ # Если мы здесь, значит, команда найдена.
>····fi
>··done
>··IFS=$oldIFS
>··return $result
>}
>checkForCmdInPath()
>{
>··var=$1
>··if ["$var"!= ""]; then
>
>
>········return 1
>······fi
>
>······return 2
>····fi
>··fi
>}
В главе 0 мы рекомендовали создать в своем домашнем каталоге новую папку scripts и добавить полный путь к ней в свою переменную окружения PATH. Выполните команду echo $PATH, чтобы увидеть текущее значение переменной PATH, и добавьте в сценарий входа (.login, profile, bashrc или .bash_profile, в зависимости от оболочки) строку, изменяющую значение PATH. Подробности ищите в разделе «Настройка оболочки входа» в главе 0.
Если попробовать вывести список файлов в каталоге с помощью команды ls, некоторые специальные файлы, такие как .bashrc и .bash_profile, могут не отображаться. Это объясняется тем, что файлы, имена которых начинаются с точки, например
