Bash by example / Bash в примерах: Part 1: Fundamental programming in the Bourne again shell (bash)

Введение

Daemon786 12.01.11 в 13:06

Возможно вы спросите, зачем вам изучать программирование в Bash. Вот пара веских причин для его изучения:

neumann16 28.04.11 в 08:32

Вы уже запустили его

Daemon786 12.01.11 в 14:41

Если вы проверите, то вероятно обнаружите, что вы уже запустили bash (прямо сейчас). Даже если вы изменили свою оболочку по умолчанию, bash наверное по-прежнему будет работать в вашей системе, так как это стандартная оболочка Linux и используется для различных целей. Поскольку bash уже загружен, любые дополнительные bash-сценарии, которые вы запустите, будут изначально эффективно использовать память, потому что они используют память совместно с любыми другими уже запущенными bash-процессами. Почему загрузка 500 килобайтного интерпретатора, если вы уже запустили что-либо, будет делать работу, и сделает это хорошо?

Daemon786 12.01.11 в 14:41

Выуже используете его

Daemon786 12.01.11 в 14:41

Вы не только уже используете его, но и ежедневно взаимодействуете с bash. И это всегда так, поэтому важно узнать как использовать его потенциал полностью. Это сделает вашу работу с bash более приятной и плодотворной. Но почему вы должны освоить программирование в bash? Просто потому, что вы уже думаете о запуске команд, копировании файлов, перенаправлении потока вывода. Не должны ли вы изучить язык, позволяющий вам использовать мощные и экономящие время конструкции, которые вы уже знаете как использовать? Командные оболочки раскрывают потенциал UNIX-систем, а bash - это командная оболочка в Linux. Это связь между вами и машиной на высоком уровне. Совершенствуя ваши знания о bash, вы одновременно повысите продуктивность своей работы с Linux и UNIX -- это так просто.

Clyde 12.01.11 в 18:18

Путаница в bash

Daemon786 13.01.11 в 09:55

Неправильное изучение bash может сильно запутать. Многие новички открывают man, чтобы прочитать руководство пользователя bash, и сталкиваются только лишь с кратким техническим описанием функций оболочки. Другие открывают info (чтобы посмотреть докумнетацию GNU) и получают ту же самую страницу man или (если повезет) только слегка упрощенную её версию.

Clyde 12.01.11 в 18:38

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

Clyde 12.01.11 в 18:46

Вот для чего предназначено это руководство. Здесь я покажу вам как нужно программировать в bash, вы научитесь писать свои собственные скрипты. В отличии от технических описаний, я буду объяснять на простом языке так, что вы будете не только знать как что-то работает, но и когда вы должны это использовать. К концу этого руководства из трех частей вы сможете писать свои замысловатые скрипты в bash и выйдите на уровень, необходимый для комфортного использования bash и пополнения своих знаний путем чтения (и понимания!) стандартной документации bash. Давайте начнем.

Clyde 12.01.11 в 19:02

Переменные окружения

Clyde 12.01.11 в 17:46

В bash и почти во всех других оболочках пользователь может определять переменные окружения, которые хранятся в виде ASCII строки. Одно из удобств переменных окружения заключается в том, что они являются стандартной частью модели процессов в UNIX. Это значит, что переменные окружения могут быть использованы не только в скриптах оболочки, но так же и в обычных программамах. Когда мы "экспортируем" переменную окружения в bash, последующие программы, которые мы запустили позже, могут прочитать нашу переменную, будь то скрипт оболочки или нет. Хорошим примером является команда vipw, которая позволяет суперпользователю редактировать системный файл паролей. Установив в переменную окружения EDITOR имя вашего любимого текстового редактора, вы можете использовать vipw вместо vi, это удобно, если вы привыкли к xemacs и не любите vi.

Clyde 15.01.11 в 09:52

Стандартный способ определения переменной окружения:

Daemon786 13.01.11 в 09:49

$ myvar='This is my environment variable!'

Daemon786 12.01.11 в 14:39

Приведенная выше команда определяет переменную окружения с названием "myvar", содержащую в себе строку "This is my environment variable!". Здесь есть несколько вещей, на которые следует обратить внимание: во-первых, не должно быть пробелов с обеих сторон от знака "="; любой пробел приведет к ошибке (попробуйте это и увидите сами). Во-вторых, стоит отметить то, что мы можем избавиться от кавычек, если определяем одно слово, но они необходимы, когда значение переменной состоит более чем из одного слова (содержит пробелы и табуляции).

Daemon786 14.01.11 в 08:42

Примечание

Daemon786 13.01.11 в 09:50

За подробной информации о том, как должны быть использованы кавычки, вы можете обратиться в раздел "QUOTING" на man-странице bash. Существование специальных последовательностей символов, которые "подставляются" (заменяются) другими значениями усложняет обработку строк в bash. В этом руководстве мы покроем только наиболее часто используемые функции кавычек.

Clyde 15.01.11 в 10:46

Далее, хотя мы можем использовать двойные кавычки вместо одинарных, в предыдущем примере это привело бы к ошибке. Почему? Потому что одинарные кавычки отключают функцию bash называемую подстановкой, когда специальные символы и последовательности символов заменяются своими значениями. Например, "!" -- это символ, который bash обычно заменяет командой, напечатанной перед этим. (Мы не будем покрывать это в данных статьях, так как это редко используется при программировании в bash. Для подробной информации об этом смотрите раздел "HISTORY EXPANSION" на man-странице bash.) Хотя такая расширенная функциональность может пригодиться, сейчас нам нужен восклицательный знак в конце переменной окружения, а не расширенная функциональность.

Clyde 15.01.11 в 11:23

Теперь давайте посмотрим как в действительности используют переменные окружения. Вот пример:

Daemon786 13.01.11 в 11:49

$ echo $myvar

Daemon786 12.01.11 в 14:39

This is my environment variable!

Daemon786 12.01.11 в 14:39

Предваряя имя нашей переменной окружения знаком $, мы заставляем bash подставить значение myvar. В терминах bash это называется "подстановка переменной". Но что, если мы попробуем следующее:

Clyde 15.01.11 в 10:06

$ echo foo$myvarbar

Daemon786 12.01.11 в 14:39

foo

Daemon786 12.01.11 в 14:38

Мы хотели вывести "fooThis is my environment variable!bar", но это не сработало. Что пошло не так? Вкратце, средство bash, подставляющее значения переменных, было сбито с толку. Данная команда не определяет хотели ли мы подставить значение переменной $m, $my, $myvar, $myvarbar и так далее. Как мы можем более четко и ясно сказать bash какую переменную мы меем в виду? Попробуйте это:

Clyde 15.01.11 в 10:29

$ echo foo${myvar}bar

Daemon786 12.01.11 в 14:38

fooThis is my environment variable!bar

Daemon786 12.01.11 в 14:38

Как вы можете видеть, мы можем заключить имя переменной окружения в фигурные скобки, когда оно четко не отделено от текста. Хотя ввести $myvar быстрее и это будет работать в большинстве случаев, ${myvar} может быть обработано правильно практически в любой ситуации. Кроме того, они делают одно и то же и вы будете видеть обе формы подстановки переменных до конца руководства. Запомните использовать более ясную форму -- ограничение фигурными скобками, когда ваша переменная окружения не изолирована от текста (пробелами или символами табуляции).

Clyde 15.01.11 в 11:38

Напоминаю, что мы также упоминали, что мы можем "экспортировать" переменные. Когда мы экспортируем переменную окружения, она автоматически становится доступна в окружении любого запущенного позднее скрипта или исполняемого файла. Скрипты оболочки могут "добраться" до переменной окружения используя встроенную в оболочку поддержку переменных окружения, а программы на C могут использовать функцию getenv(). Вот пример кода на C, который вы должны ввести и скомпилировать -- это позволит нам понять переменные окружения с точки зрания C:

Clyde 15.01.11 в 11:52

#include
#include

int main(void) {
char *myenvvar=getenv("EDITOR");
printf("The editor environment variable is set to %s
",myenvvar);
}

Clyde 12.01.11 в 19:09

Сохраните приведенный выше код в файл с названием myenv.c и затем скомпилируйте его с помощью команды:

Clyde 15.01.11 в 11:53

$ gcc myenv.c -o myenv

Daemon786 13.01.11 в 09:30

Так в текущей директории мы получим исполняемый файл, который после запуска напечатает значение переменной окружения EDITOR, если таковая установлена. Вот что получается, когда я запускаю его на своем компьютере:

Clyde 15.01.11 в 11:56

$ ./myenv
The editor environment variable is set to (null)

Daemon786 13.01.11 в 09:30

Хммм... из-за того, что переменная окружения EDITOR не была установлена, программа получает пустую строку. Давайте попробуем присвоить ей специальное значение:

Clyde 15.01.11 в 11:58

$ EDITOR=xemacs
$ ./myenv
The editor environment variable is set to (null)

Daemon786 13.01.11 в 09:30

Хотя вы вероятно ожидали, что myenv напечатает "xemacs", это не сработало, потому что мы не экспортировали переменную окружения EDITOR. Сейчас мы это исправим:

Clyde 15.01.11 в 12:00

$ export EDITOR
$ ./myenv
The editor environment variable is set to xemacs

Daemon786 13.01.11 в 09:30

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

Daemon786 17.01.11 в 10:44

$ export EDITOR=xemacs

Daemon786 13.01.11 в 09:30

Это работает аналогично версии с двумя строками. Теперь самое время, чтобы показать как очистить переменную окружения, используя unset:

Daemon786 17.01.11 в 11:29

$ unset EDITOR
$ ./myenv
The editor environment variable is set to (null)

Daemon786 13.01.11 в 09:30

Обзор разбиения строк

Daemon786 17.01.11 в 08:54

Разбиение строк -- то есть разделение исходной строки на более маленькие, отдельные куски(-ок) -- одна и тех задач, которые выполняются ежедневно вашими рядовыми сценариями оболочки. Многократно сценариям требуется взять полный путь и найти в нем только имя файла или директории. Хотя это возможно (и весело!) написать программу для этого в bash, стандартный исполняемый файл UNIX -- basename делает это очень хорошо.

Daemon786 17.01.11 в 12:51

$ basename /usr/local/share/doc/foo/foo.txt
foo.txt
$ basename /usr/home/drobbins
drobbins

Daemon786 13.01.11 в 08:36

basename довольно удобный инструмент разбиения строк. Его спутник называется "dirname", возвращает "другую" часть пути, которую basename отбрасывает:

Daemon786 17.01.11 в 13:03

$ dirname /usr/local/share/doc/foo/foo.txt
/usr/local/share/doc/foo
$ dirname /usr/home/drobbins/
/usr/home

Daemon786 13.01.11 в 08:39

Примечание

Daemon786 13.01.11 в 09:50

И dirname и basename не смотрят на какие-либо файлы или директории на диске, они исключительно команды обработки строк.

Daemon786 17.01.11 в 13:09

Подстановка команд

Daemon786 17.01.11 в 13:10