Linuxformat - Вклад участника [ru]

LXF97:Python

2008-03-19T23:45:51Z

OWeRQ:

== Python: Управляемся ==
''Надоело мириться с дезориентирующими тэгами и нелепыми именами файлов?
Укодируйте их до полного исчезновения с помощью '''Ника Вейча''' и магии Python!''

Правда-правда, я ужасно люблю порядок: все вещи на своем
месте, все под рукой, и вы можете мигом определить, что
есть, чего нет; и всякое такое. Впрочем, люди, видевшие фото
моего рабочего стола или совавшие нос в мой бельевой ящик, пожалуй, оторопеют от явной лживости этого высказывания. Но, пожалуйста, внимательно прочтите его еще раз: я сказал, что люблю порядок, а
вовсе не что я люблю его наводить. Моя мечта – чтобы во всех комнатах моего дома стояло по хитроумной мусорной корзине, связанной с
этаким интеллектуальным сканером объектов: каждый раз, покончив с
использованием/чтением/изучением чего-либо, я бы просто скидывал
эту штуку в мусоросборник, а она волшебным образом перемещалась
куда-нибудь и дожидалась там своего часа. Увы, похоже, подобные
технологии не скоро до меня доберутся. Сейчас самая моя больная
тема – музыкальная коллекция. Я, конечно, целиком за свободу творчества, но то, что все мои сборники CD имеют разные шрифты, цвета и
формат хранения данных, действует на нервы. Впрочем, виртуальный
мир вашей Linux-системы способен удовлетворить любые ваши прихоти, включая страсть к педантизму и скрупулезной правильности!

Python – превосходный язык для выполнения стандартных операций с файлами. Он позволяет обрабатывать имена файлов и использовать функциональные возможности ОС с помощью ряда встроенных
функций, всегда готов при необходимости вызвать внешние утилиты,
имеет огромную коллекцию готовых модулей, способных выполнить
практически любые действия, и к тому же очень прост для понимания.
Он хорош не только для прототипирования, но и для создания самостоятельных приложений – или как минимум удобных небольших сценариев для выполнения частных задач.

Итак, наша цель – разобраться с коллекцией музыкальных файлов
на моем Linux-компьютере (отдельным счастливчикам это тоже при-
годится). У меня есть один большой каталог под названием ‘Music’,
который, как полагается, делится на подкаталоги по исполнителям,
альбомам и отдельным трекам. Однако, несмотря на столь стройную
систему, у меня имеются проблемы непосредственно с музыкальными
файлами. Вот примерный список вещей, мешающих мне насладиться
моей коллекцией:

* Некоторые файлы имеют слишком длинные имена, затрудняющие работу с ними. Такое бывает с покупной музыкой: в название
включается сразу и альбом, и имя исполнителя, и номер дорожки, и
т.д. Я же хочу единый для всех названий вид, желательно без дурацких символов.
* Некоторые файлы содержат тэги формата ID3v1, а не ID3v2. Беда
небольшая, но по возможности я бы предпочел наслаждаться и преимуществами ID3v2.
* Некоторые файлы снабжены тэгами формата ID3v2, но не ID3v1.
Из-за этого они не читаются на стареньком MP3-плейере в моем
автомобиле.
* Некоторые из файлов неработоспособны. Неплохо было бы
иметь список дефектных файлов, чтобы удалить их из коллекции
или заменить.
* Некоторые из файлов сохранены в нетипичных форматах, которые распознаются не всеми доступными устройствами. Список этих
файлов тоже пригодился бы.

Но как же достичь хотя бы части этих целей? Хоть я и не вполне уверен, что все перечисленные мной желания легко выполнимы, но попытаться стоит; по крайней мере, я знаю, с чего начать. В Python’е имеется
модуль под названием os. Он реализует все стандартные функции ОС,
в частности, связанные с файловой системой. Python – кросс-платформенная разработка, поэтому, несмотря на различия реализации в разных операционных системах, задача у данного модуля одна: предоставление функциональности уровня ОС с единым интерфейсом. Одной из
самых полезных из известных мне функций, представленных в данном
модуле, является walk(). Если задать ей имя родительского каталога,
эта функция вернет список кортежей (см. врезку слева), включающих
имя родительского каталога, список подкаталогов (если они есть) и
список имен файлов. Таким образом, чтобы получить список всех файлов, включая полный путь к ним, нужно выполнить функцию walk() с
заданным нами каталогом и по шагам обработать результат.

==== Что такое «кортеж»? (врезка) ====
Кортеж – это объект, состоящий из нескольких значений. Он часто
используется в Python. Хороший пример использования кортежа –
цвет. Вместо того, чтобы хранить три значения в трех разных переменных для красного, зеленого и синего цветов, вы назначаете одну переменную, содержащую три значения! Кортеж в Python записывается
примерно так: (123,255,17). Вы можете получить доступ к любому элементу кортежа с помощью индексов – значений в квадратных скобках,
указываемых после имени переменной. Например, команда print
Colour[1] вернет значение «255» в случае с предыдущим примером –
только не забывайте, что значения индексов начинаются с 0!

=== Python и музон ===
<code>
import os
topdir=”/usr/share/music/”
walklist = os.walk(topdir)
for dirs in walklist:
if(dirs[2]):
for file in dirs[2]:
// Выполнить какое-нибудь действие
print os.path.join(dirs[0],file)
else:
for entry in dirs[1]:
print dirs[1]
</code>

В данном примере мы сначала импортируем модуль os, затем
назначаем каталог, который хотим использовать. В результате выполнения функции walk() генерируется объект в переменной walklist. С
помощью конструктора for мы можем затем использовать имеющийся в Python способ пошагового перемещения по списку для работы с
каждым элементом. Чтобы вам стало понятнее, данные переменной
walklist должны выглядеть примерно так:

<code>
(‘/usr/share/music/Blonde_Redhead’, [‘1980 Forward’, ‘23’], [])
(‘/usr/share/music/Blonde_RedHead/1980 Forward’, [], [‘18-Magic
Mountain.mp3’])
(‘/usr/share/music/Blonde_Redhead/23’, [], [‘10-My Impure Hair.
mp3’,’1-23.mp3’, ‘7-Publisher.mp3’, ‘3-The Dress.mp3’, ‘6-Silently.
mp3’])
</code>

Теперь пошагово проверим каждую строку. Если элемент строки
является файлом (одним или несколькими, в виде списка), мы хотим
выполнить с ним определенные действия. Оператор if проверяет, имеется ли что-нибудь в каталоге, а если имеется, мы продолжим перемещаться по списку файлов тем же способом. Что делать с файлами,
пока не совсем ясно, поэтому просто распечатаем список в стандартный вывод. Здесь мы воспользуемся другой полезной функцией модуля os – os.path.join(). Она соединяет вместе все компоненты пути к
файлу и записывает их в виде, соответствующем текущему модулю os,
что, несомненно, гораздо лучше, чем простое соединение вхождений с
помощью слэша /, как это обычно делается в Linux!

Я также добавил здесь еще одну ветку else – на случай, если мы
захотим что-то проделать и с каталогами (может, переименовать?). Но
для начала просто выполните данный скрипт, чтобы проверить, работает ли он в вашей системе. Главное – не забудьте указать именно
тот каталог, где действительно имеются MP3-файлы.

==== Проверка типов файлов ====
Ну вот, теперь самое время добавить новые функции в данный скрипт.
Но прежде чем приняться за файл, я предлагаю убедиться, что он действительно музыкальный! Думаю, мы можем смело предположить,
что все MP3-файлы имеют расширение mp3. Таким образом, в нашем
цикле мы могли бы проверить это и пометить файлы, не соответствующие данному критерию. Вероятно, мы могли бы просто включить
такую проверку внутри цикла, уже осуществляемого оператором if, но
так как проверка может потребоваться не одна, гораздо разумнее присвоить расширение переменной и затем проверять ее. Для извлечения
расширения воспользуемся простым и мощным способом обработки
строк и переменных других типов в Python (подробнее – см. врезку
справа вверху). Добыв расширение файла, можно проверить, не совпадает ли оно с другими форматами музыкальных файлов, вроде ‘.wma’
и ‘.ogg’ – на случай, если мы захотим поработать и с такими файлами.
В Python нет оператора case:; придется нагромоздить последовательность операторов if, elif (else if) и else. Символ # в Python указывает, что
оставшаяся часть строки – комментарий. В итоге наш основной цикл
примет такой вид:

<code>
for file in dirs[2]:
fullpath = os.path.join(dirs[0],file)
extension = file[-4:]
if (extension!=’.mp3’):
# Это не MP3-файл; проверить на другие расширения?
if (extension ==’.wma’):
wmalist.append(fullpath)
elif (extension ==’.ogg’):
ogglist.append(fullpath)
else:
unknownlist.append(fullpath)
else:
# Это MP3-файл.
# Что-нибудь с ним сделаем.
print fullpath
</code>

Мы также должны объявить три переменных типа «список» в
основном коде. Возможно, вы захотите добавить код, обрабатывающий файлы, или указать другие варианты расширений. Для полноты
картины, создадим также список неизвестных типов файлов, найденных в нашем каталоге – чисто информативный; заодно он поможет
обнаружить то, что мы упустили.
Теперь займемся MP3-файлами. Спецификация ID3v1 весьма
незамысловата: в конец файла просто добавляется 128 байт информации о файле, и легко создать синтаксический анализатор для сбора
этих данных и дальнейшей обработки. Однако ID3v2 придерживается
других стандартов: информация заносится в начало файла, в виде
сложной структуры с переменной длиной данных, и, если честно, нам
пришлось бы изрядно разрастить наш маленький скрипт, чтобы с ней
справиться. Поэтому мы поступим, как все нормальные программисты:
схитрим! Существует множество готовых модулей Python, способных
читать данные MP3-тэгов, вот и возьмем один из них. Рекомендую
EyeD3 – это признанный фаворит, и в нем есть все, что нам нужно. Вы
найдете его на DVD, прилагаемом к данному журналу, а на сайте http://
eyed3.nicfit.net может оказаться более свежая версия.
Данный модуль творит всяческие чудеса; некоторые из них нам
даже и трогать незачем. Вы можете почитать о нем подробнее на указанном сайте, но для наших целей достаточно импортировать модуль
и ознакомиться с функциями, которые нам пригодятся.
К счастью, модуль eyeD3 не относится к числу сложных. Опасения
внушает только один объект – eyeD3.Tag, содержащий структуру тэгов
ID3v1 и ID3v2. Чтобы заполнить его данными из вашего файла, вы
должны использовать метод объекта link с соответствующим именем
файла, и выглядит это примерно так:

<code>
mytag=eyeD3.Tag()
mytag.link(‘/usr/share/music/Blonde_Redhead/23/1-23.mp3’)
print mytag.getArtist()
print mytag.getAlbum()
print mytag.getTrackNum()
</code>

Изменив любой из тэгов, просто вызовите метод tag.update(), и
он запишет новый тэг в файл. Теперь разберемся, как мы поступим с
нашими файлами. Вместо того, чтобы сразу создавать необходимый
код, я обычно просто вписываю набор операций, которые нужно сделать, в виде комментариев. Потом можно легко сортировать их, разбивать на более мелкие действия, или, в конце концов, собраться с духом
и дописать требуемый код! Ниже представлен примерный список операций над нашими файлами, которые могли бы понадобиться:

* Получить расширение файла
* Он заканчивается на .mp3?
* Проверить, действительно ли это MP3-файл
* Прочитать тэги версии 2
* Прочитать тэги версии 1
* Если имеется только один тип, копировать в другой тип
* Если тэгов вообще нет, установить пометку
* Создать нормальное имя файла из тэгов
* Предложить/записать новое имя файла
* Проверить, соответствует ли название альбома имени каталога
* Если это не MP3-файл, то что? Добавить в соответствующий список

Как сказано выше, впишем это в скрипт в виде комментариев.
Обычно приступать к делу лучше с первого пункта, чтобы от вас не
ускользнули логика действий и структура скрипта. Особо хитрые участки – или участки, используемые многократно – можно вынести в
отдельную функцию. Существуют мнения и за и против этого, и программисты нередко обсуждают, что допустимо выделять в отдельную
функцию. Теория выглядит примерно так: чем больше вы выносите из
основного цикла программы, тем более очевидной становится общая
задача. Но есть и контрдовод: чем больше вы включаете подобных
обобщений, делая программу максимально простой и понятной, тем
сложнее потом добраться до работы отдельных функций. Резюме:
поскольку вы пишете программу исключительно для личного пользования, делайте так, как вам удобнее!

==== Проверка типов файлов – 2 ====
Теперь пора и делом заняться. Прежде всего, получим расширения
файлов через слайсинг Python’а, а затем проверим, MP3 это или нет.
После чего употребим модуль eyeD3, чтобы распознать, действительно
ли файл соответствует заявленному формату.

После операторов проверки сделаем отступы, чтобы было видно,
какой блок кода используется при обнаружении соответствия, и воз-
вратимся к оператору else. В данном случае я слегка поменил порядок
действий, для начала разобравшись с файлами, не соответствующими
формату MP3, а затем через оператор else перешел к дальнейшим
действиям. Почему? Да просто очень легко позабыть про файлы, не
интересующие вас в данный момент; если вы можете парой строк отде-
латься от второстепенных данных, лучше сразу с ними и покончить. В
конечном итоге, быть может, у нас появится специальная функция для
их обработки.

В представленном ниже коде можно встретить так называемые
функции «санации» (sanitize). Присутствие их тела в основном коде
сделало бы его неудобочитаемым, кроме того, иногда их бывает нужно
вызывать из разных мест. Наконец, так с их реализацией можно разо-
браться и позже, не затрагивая основной код.

<code>
if (extension !=’.mp3’):
# Не файл MP3? Проверить на другие расширения?
if (extension == ‘.wma’):
wmalist.append(fullpath)
# logger.warn(“silly wma file %s”,fullpath)
elif (extension == ‘.ogg’):
ogglist.append(fullpath)
else:
unknownlist.append(fullpath)
else:
# Это вправду MP3-файл?
if eyeD3.isMp3File(fullpath):
# Прочитать тэг ID3V2
tag2 = eyeD3.Tag()
tag1 = eyeD3.Tag()
a = tag2.link(fullpath,eyeD3.ID3_V2)
b = tag1.link(fullpath,eyeD3.ID3_V1)
if b and not a:
# Имеется только тэг ID3v1
print “version1 only”
# Создать информацию для tag2 по tag1
print fullpath
artist = tag1.getArtist()
album = tag1.getAlbum()
title = tag1.getTitle()
print artist,album,title
tag1.update(eyeD3.ID3_V2)
# check tags are cool
elif a and not b:
# Имеется только тэг ID3v2
print fullpath
artist = tag2.getArtist()
album = tag2.getAlbum()
title = tag2.getTitle()
print artist,album,title
try:
tag2.update(eyeD3.ID3_V1_1)
except UnicodeEncodeError:
logger.error(“tag invalid for v1.1 in file %s”, fullpath)
elif a and b:
# Имеются оба тэга
logger.info( “both versions fine %s”, fullpath)
else:
# Тэгов нет вообще
logger.warn(‘this file has no tags! %s’, fullpath)
error_flag = True
# М.б. удастся вытянуть что-нибудь из имени каталога, где сидит файл!
if not error_flag:
# Пускай имя файла будет
# number-name.mp3
title=tag2.getTitle()
title = title.replace(‘ ‘,’_’)
n=tag2.getTrackNum()
# Номер (number) у нас есть
ns = str(n[0])
if len(ns)==1:
ns= ‘0’+ns
ns=ns+’-’+title+’.mp3’
# Уберем нехорошие символы
ns=sanitize(ns)
if (file!=ns):
logger.info(“change filename suggested for %s, to %s!”,filename,ns)
os.rename(fullpath, os.path.join(dirs[0],ns)
else:
# Выдадим предупреждение
logger.warn(“ file %s does not seem to be a valid mp3 file”,fullpath)
</code>

Полная распечатка этого небольшого скрипта представлена на
DVD данного номера Linux Format. Но будьте осторожны – скрипт не
завершен! Нельзя гарантировать, что он не испортит вашу музыкаль-
ную коллекцию! Особенно следует обратить внимание на проверку
символов в кодировке Unicode, нередко встречающихся в тэгах ID3v2
(недопустимых в тэгах первой версии). Также вы, возможно, захотите
обработать и файлы формата .ogg.

Здесь не доделано также множество проверок на ошибки. В случае
с тэгами в кодировке Unicode поможет структура try: ... except:; она же
пригодится и для других случаев (например, выяснении, как поступать
с музыкальными файлами без прав доступа на запись). Но я надеюсь,
что рассмотренный в статье пример показал вам, как просто создавать
полезные скрипты!

==== Будем резать! (врезка) ====
В Python используются индексы для «нарезания на кусочки» (иногда говорят «слайсинг»,
от англ. slicing) строк, списков и других типов
переменных. Пусть у нас имеется запись plop.
mp3; мы можем запросто извлечь из нее
любой нужный нам бит. Откройте терминал,
запустите Python для входа в интерактивный
режим и попробуйте следующие команды:

<code>
>>> string = ‘plop.mp3’
>>> print string[1]
l
>>> print string[:2]
pl
>>> print string [-0]
p
>>> print string [-1]
3
>>> print string [-4:]
.mp3
>>>
</code>

В последнем операторе print из строки выхватываются четыре последних символа.
Отрицательные индексы отсчитываются с конца строки, но будьте внимательны: -0 означает

==== Журналирование (врезка) ====
Небольшие скрипты часто нашпиговывают множеством выводов промежуточных данных на
печать, чтобы знать, что и как происходит. Это действительно удобно; но иногда хочется превратить строку с оператором печати в комментарий, потом снова её подключить, и т.д. Проще всего
в таком случае использовать встроенный в Python модуль ведения журнала! Он умеет выводить
сообщения и в консоль, но способен различать сообщения по значимости, и вы сможете гибко
регулировать количество выводов на консоль путём правки всего одной строки кода скрипта.
Добавьте этот модуль к списку импортируемых и впишите следующий код в начало вашего
скрипта:

<code>
logger = logging.getLogger(“pymusic”)
# Создать обработчик консоли
handler = logging.StreamHandler()
# Создать форматирование и настроить обработчик на его использование
formatter = logging.Formatter(“%(asctime)s - %(name)s - %(levelname)s - %(message)s”)
handler.setFormatter(formatter)
# Добавить обработчик к модулю ведения журнала
logger.addHandler(handler)
logger.setLevel(logging.WARN)
</code>
Часть этих штук смахивает на волшебство, и кое-кто считает модуль ведения журнала непостижимым, но на самом деле все очень просто. Если вы хотите узнать больше, документация
находится здесь: http://docs.python.org/lib/module-logging.html. Фактически, всё, что необходимо
знать – это набор стандартных команд для управления выводом сообщений в консоль.
Например, следующий код:

<code>
logger.warn(“ file %s does not seem to be a valid mp3 file”,fullpath)
</code>

выведет в консоль только сообщения, относящиеся к предупреждениям типа WARN или ниже
(порядок такой: Critical, Error, Warning, Info, Debug). Можно установить и собственные уровни, но
мы займёмся этим в другой раз...
то же самое, что и просто 0, а именно – начало
строки! (Индексы в Python нумеруются с 0.)

==== Форматирование (врезка) ====
Необходимость чёткого форматирования кода в Python многих ставит
в тупик, но это вполне простое и разумное требование. В частности,
отступы строк (посредством пробелов или табуляции) в блоке кода
должны быть одинаковыми, потому что в Python отступы являются
значимыми. Взглянув на код, вы не увидите фигурных скобок вокруг
любых операторов или блоков кода: Python распознаёт окончание блока по окончанию отступа. Это даёт сразу два преимущества: код становится гораздо удобнее для чтения, и не надо заботиться о вложенных
фигурных скобках!

LXF97:Python

2008-03-19T23:40:47Z

OWeRQ: Новая: == Python: Управляемся == ''Надоело мириться с дезориентирующими тэгами и нелепыми именами файлов? Укодиру...

== Python: Управляемся ==
''Надоело мириться с дезориентирующими тэгами и нелепыми именами файлов?
Укодируйте их до полного исчезновения с помощью '''Ника Вейча''' и магии Python!''

Правда-правда, я ужасно люблю порядок: все вещи на своем
месте, все под рукой, и вы можете мигом определить, что
есть, чего нет; и всякое такое. Впрочем, люди, видевшие фото
моего рабочего стола или совавшие нос в мой бельевой ящик, пожалуй, оторопеют от явной лживости этого высказывания. Но, пожалуйста, внимательно прочтите его еще раз: я сказал, что люблю порядок, а
вовсе не что я люблю его наводить. Моя мечта – чтобы во всех комнатах моего дома стояло по хитроумной мусорной корзине, связанной с
этаким интеллектуальным сканером объектов: каждый раз, покончив с
использованием/чтением/изучением чего-либо, я бы просто скидывал
эту штуку в мусоросборник, а она волшебным образом перемещалась
куда-нибудь и дожидалась там своего часа. Увы, похоже, подобные
технологии не скоро до меня доберутся. Сейчас самая моя больная
тема – музыкальная коллекция. Я, конечно, целиком за свободу творчества, но то, что все мои сборники CD имеют разные шрифты, цвета и
формат хранения данных, действует на нервы. Впрочем, виртуальный
мир вашей Linux-системы способен удовлетворить любые ваши прихоти, включая страсть к педантизму и скрупулезной правильности!

Python – превосходный язык для выполнения стандартных операций с файлами. Он позволяет обрабатывать имена файлов и использовать функциональные возможности ОС с помощью ряда встроенных
функций, всегда готов при необходимости вызвать внешние утилиты,
имеет огромную коллекцию готовых модулей, способных выполнить
практически любые действия, и к тому же очень прост для понимания.
Он хорош не только для прототипирования, но и для создания самостоятельных приложений – или как минимум удобных небольших сценариев для выполнения частных задач.

Итак, наша цель – разобраться с коллекцией музыкальных файлов
на моем Linux-компьютере (отдельным счастливчикам это тоже при-
годится). У меня есть один большой каталог под названием ‘Music’,
который, как полагается, делится на подкаталоги по исполнителям,
альбомам и отдельным трекам. Однако, несмотря на столь стройную
систему, у меня имеются проблемы непосредственно с музыкальными
файлами. Вот примерный список вещей, мешающих мне насладиться
моей коллекцией:

* Некоторые файлы имеют слишком длинные имена, затрудняющие работу с ними. Такое бывает с покупной музыкой: в название
включается сразу и альбом, и имя исполнителя, и номер дорожки, и
т.д. Я же хочу единый для всех названий вид, желательно без дурацких символов.
* Некоторые файлы содержат тэги формата ID3v1, а не ID3v2. Беда
небольшая, но по возможности я бы предпочел наслаждаться и преимуществами ID3v2.
* Некоторые файлы снабжены тэгами формата ID3v2, но не ID3v1.
Из-за этого они не читаются на стареньком MP3-плейере в моем
автомобиле.
* Некоторые из файлов неработоспособны. Неплохо было бы
иметь список дефектных файлов, чтобы удалить их из коллекции
или заменить.
* Некоторые из файлов сохранены в нетипичных форматах, которые распознаются не всеми доступными устройствами. Список этих
файлов тоже пригодился бы.

Но как же достичь хотя бы части этих целей? Хоть я и не вполне уверен, что все перечисленные мной желания легко выполнимы, но попытаться стоит; по крайней мере, я знаю, с чего начать. В Python’е имеется
модуль под названием os. Он реализует все стандартные функции ОС,
в частности, связанные с файловой системой. Python – кросс-платформенная разработка, поэтому, несмотря на различия реализации в разных операционных системах, задача у данного модуля одна: предоставление функциональности уровня ОС с единым интерфейсом. Одной из
самых полезных из известных мне функций, представленных в данном
модуле, является walk(). Если задать ей имя родительского каталога,
эта функция вернет список кортежей (см. врезку слева), включающих
имя родительского каталога, список подкаталогов (если они есть) и
список имен файлов. Таким образом, чтобы получить список всех файлов, включая полный путь к ним, нужно выполнить функцию walk() с
заданным нами каталогом и по шагам обработать результат.

==== Что такое «кортеж»? (врезка) ====
Кортеж – это объект, состоящий из нескольких значений. Он часто
используется в Python. Хороший пример использования кортежа –
цвет. Вместо того, чтобы хранить три значения в трех разных переменных для красного, зеленого и синего цветов, вы назначаете одну переменную, содержащую три значения! Кортеж в Python записывается
примерно так: (123,255,17). Вы можете получить доступ к любому элементу кортежа с помощью индексов – значений в квадратных скобках,
указываемых после имени переменной. Например, команда print
Colour[1] вернет значение «255» в случае с предыдущим примером –
только не забывайте, что значения индексов начинаются с 0!

=== Python и музон ===
<code>
import os
topdir=”/usr/share/music/”
walklist = os.walk(topdir)
for dirs in walklist:
if(dirs[2]):
for file in dirs[2]:
// Выполнить какое-нибудь действие
print os.path.join(dirs[0],file)
else:
for entry in dirs[1]:
print dirs[1]
</code>

В данном примере мы сначала импортируем модуль os, затем
назначаем каталог, который хотим использовать. В результате выполнения функции walk() генерируется объект в переменной walklist. С
помощью конструктора for мы можем затем использовать имеющийся в Python способ пошагового перемещения по списку для работы с
каждым элементом. Чтобы вам стало понятнее, данные переменной
walklist должны выглядеть примерно так:

<code>
(‘/usr/share/music/Blonde_Redhead’, [‘1980 Forward’, ‘23’], [])
(‘/usr/share/music/Blonde_RedHead/1980 Forward’, [], [‘18-Magic
Mountain.mp3’])
(‘/usr/share/music/Blonde_Redhead/23’, [], [‘10-My Impure Hair.
mp3’,’1-23.mp3’, ‘7-Publisher.mp3’, ‘3-The Dress.mp3’, ‘6-Silently.
mp3’])
</code>

Теперь пошагово проверим каждую строку. Если элемент строки
является файлом (одним или несколькими, в виде списка), мы хотим
выполнить с ним определенные действия. Оператор if проверяет, имеется ли что-нибудь в каталоге, а если имеется, мы продолжим перемещаться по списку файлов тем же способом. Что делать с файлами,
пока не совсем ясно, поэтому просто распечатаем список в стандартный вывод. Здесь мы воспользуемся другой полезной функцией модуля os – os.path.join(). Она соединяет вместе все компоненты пути к
файлу и записывает их в виде, соответствующем текущему модулю os,
что, несомненно, гораздо лучше, чем простое соединение вхождений с
помощью слэша /, как это обычно делается в Linux!

Я также добавил здесь еще одну ветку else – на случай, если мы
захотим что-то проделать и с каталогами (может, переименовать?). Но
для начала просто выполните данный скрипт, чтобы проверить, работает ли он в вашей системе. Главное – не забудьте указать именно
тот каталог, где действительно имеются MP3-файлы.

==== Проверка типов файлов ====
Ну вот, теперь самое время добавить новые функции в данный скрипт.
Но прежде чем приняться за файл, я предлагаю убедиться, что он действительно музыкальный! Думаю, мы можем смело предположить,
что все MP3-файлы имеют расширение mp3. Таким образом, в нашем
цикле мы могли бы проверить это и пометить файлы, не соответствующие данному критерию. Вероятно, мы могли бы просто включить
такую проверку внутри цикла, уже осуществляемого оператором if, но
так как проверка может потребоваться не одна, гораздо разумнее присвоить расширение переменной и затем проверять ее. Для извлечения
расширения воспользуемся простым и мощным способом обработки
строк и переменных других типов в Python (подробнее – см. врезку
справа вверху). Добыв расширение файла, можно проверить, не совпадает ли оно с другими форматами музыкальных файлов, вроде ‘.wma’
и ‘.ogg’ – на случай, если мы захотим поработать и с такими файлами.
В Python нет оператора case:; придется нагромоздить последовательность операторов if, elif (else if) и else. Символ # в Python указывает, что
оставшаяся часть строки – комментарий. В итоге наш основной цикл
примет такой вид:

<code>
for file in dirs[2]:
fullpath = os.path.join(dirs[0],file)
extension = file[-4:]
if (extension!=’.mp3’):
# Это не MP3-файл; проверить на другие расширения?
if (extension ==’.wma’):
wmalist.append(fullpath)
elif (extension ==’.ogg’):
ogglist.append(fullpath)
else:
unknownlist.append(fullpath)
else:
# Это MP3-файл.
# Что-нибудь с ним сделаем.
print fullpath
</code>

Мы также должны объявить три переменных типа «список» в
основном коде. Возможно, вы захотите добавить код, обрабатывающий файлы, или указать другие варианты расширений. Для полноты
картины, создадим также список неизвестных типов файлов, найденных в нашем каталоге – чисто информативный; заодно он поможет
обнаружить то, что мы упустили.
Теперь займемся MP3-файлами. Спецификация ID3v1 весьма
незамысловата: в конец файла просто добавляется 128 байт информации о файле, и легко создать синтаксический анализатор для сбора
этих данных и дальнейшей обработки. Однако ID3v2 придерживается
других стандартов: информация заносится в начало файла, в виде
сложной структуры с переменной длиной данных, и, если честно, нам
пришлось бы изрядно разрастить наш маленький скрипт, чтобы с ней
справиться. Поэтому мы поступим, как все нормальные программисты:
схитрим! Существует множество готовых модулей Python, способных
читать данные MP3-тэгов, вот и возьмем один из них. Рекомендую
EyeD3 – это признанный фаворит, и в нем есть все, что нам нужно. Вы
найдете его на DVD, прилагаемом к данному журналу, а на сайте http://
eyed3.nicfit.net может оказаться более свежая версия.
Данный модуль творит всяческие чудеса; некоторые из них нам
даже и трогать незачем. Вы можете почитать о нем подробнее на указанном сайте, но для наших целей достаточно импортировать модуль
и ознакомиться с функциями, которые нам пригодятся.
К счастью, модуль eyeD3 не относится к числу сложных. Опасения
внушает только один объект – eyeD3.Tag, содержащий структуру тэгов
ID3v1 и ID3v2. Чтобы заполнить его данными из вашего файла, вы
должны использовать метод объекта link с соответствующим именем
файла, и выглядит это примерно так:

<code>
mytag=eyeD3.Tag()
mytag.link(‘/usr/share/music/Blonde_Redhead/23/1-23.mp3’)
print mytag.getArtist()
print mytag.getAlbum()
print mytag.getTrackNum()
</code>

Изменив любой из тэгов, просто вызовите метод tag.update(), и
он запишет новый тэг в файл. Теперь разберемся, как мы поступим с
нашими файлами. Вместо того, чтобы сразу создавать необходимый
код, я обычно просто вписываю набор операций, которые нужно сделать, в виде комментариев. Потом можно легко сортировать их, разбивать на более мелкие действия, или, в конце концов, собраться с духом
и дописать требуемый код! Ниже представлен примерный список операций над нашими файлами, которые могли бы понадобиться:

* Получить расширение файла
* Он заканчивается на .mp3?
* Проверить, действительно ли это MP3-файл
* Прочитать тэги версии 2
* Прочитать тэги версии 1
* Если имеется только один тип, копировать в другой тип
* Если тэгов вообще нет, установить пометку
* Создать нормальное имя файла из тэгов
* Предложить/записать новое имя файла
* Проверить, соответствует ли название альбома имени каталога
* Если это не MP3-файл, то что? Добавить в соответствующий список

Как сказано выше, впишем это в скрипт в виде комментариев.
Обычно приступать к делу лучше с первого пункта, чтобы от вас не
ускользнули логика действий и структура скрипта. Особо хитрые участки – или участки, используемые многократно – можно вынести в
отдельную функцию. Существуют мнения и за и против этого, и программисты нередко обсуждают, что допустимо выделять в отдельную
функцию. Теория выглядит примерно так: чем больше вы выносите из
основного цикла программы, тем более очевидной становится общая
задача. Но есть и контрдовод: чем больше вы включаете подобных
обобщений, делая программу максимально простой и понятной, тем
сложнее потом добраться до работы отдельных функций. Резюме:
поскольку вы пишете программу исключительно для личного пользования, делайте так, как вам удобнее!

==== Проверка типов файлов – 2 ====
Теперь пора и делом заняться. Прежде всего, получим расширения
файлов через слайсинг Python’а, а затем проверим, MP3 это или нет.
После чего употребим модуль eyeD3, чтобы распознать, действительно
ли файл соответствует заявленному формату.

После операторов проверки сделаем отступы, чтобы было видно,
какой блок кода используется при обнаружении соответствия, и воз-
вратимся к оператору else. В данном случае я слегка поменил порядок
действий, для начала разобравшись с файлами, не соответствующими
формату MP3, а затем через оператор else перешел к дальнейшим
действиям. Почему? Да просто очень легко позабыть про файлы, не
интересующие вас в данный момент; если вы можете парой строк отде-
латься от второстепенных данных, лучше сразу с ними и покончить. В
конечном итоге, быть может, у нас появится специальная функция для
их обработки.

В представленном ниже коде можно встретить так называемые
функции «санации» (sanitize). Присутствие их тела в основном коде
сделало бы его неудобочитаемым, кроме того, иногда их бывает нужно
вызывать из разных мест. Наконец, так с их реализацией можно разо-
браться и позже, не затрагивая основной код.

<code>
if (extension !=’.mp3’):
# Не файл MP3? Проверить на другие расширения?
if (extension == ‘.wma’):
wmalist.append(fullpath)
# logger.warn(“silly wma file %s”,fullpath)
elif (extension == ‘.ogg’):
ogglist.append(fullpath)
else:
unknownlist.append(fullpath)
else:
# Это вправду MP3-файл?
if eyeD3.isMp3File(fullpath):
# Прочитать тэг ID3V2
tag2 = eyeD3.Tag()
tag1 = eyeD3.Tag()
a = tag2.link(fullpath,eyeD3.ID3_V2)
b = tag1.link(fullpath,eyeD3.ID3_V1)
if b and not a:
# Имеется только тэг ID3v1

print “version1 only”
# Создать информацию для tag2 по tag1
print fullpath
artist = tag1.getArtist()
album = tag1.getAlbum()
title = tag1.getTitle()
print artist,album,title
tag1.update(eyeD3.ID3_V2)
# check tags are cool
elif a and not b:
# Имеется только тэг ID3v2
print fullpath
artist = tag2.getArtist()
album = tag2.getAlbum()
title = tag2.getTitle()
print artist,album,title
try:
tag2.update(eyeD3.ID3_V1_1)
except UnicodeEncodeError:
logger.error(“tag invalid for v1.1 in file %s”,
fullpath)
elif a and b:
# Имеются оба тэга
logger.info( “both versions fine %s”, fullpath)
else:
# Тэгов нет вообще
logger.warn(‘this file has no tags! %s’, fullpath)
error_flag = True
# М.б. удастся вытянуть что-нибудь из имени
каталога, где сидит файл!
if not error_flag:
# Пускай имя файла будет
# number-name.mp3
title=tag2.getTitle()
title = title.replace(‘ ‘,’_’)
n=tag2.getTrackNum()
# Номер (number) у нас есть
ns = str(n[0])
if len(ns)==1:
ns= ‘0’+ns
ns=ns+’-’+title+’.mp3’
# Уберем нехорошие символы
ns=sanitize(ns)
if (file!=ns):
logger.info(“change filename suggested for %s, to
%s!”,filename,ns)
os.rename(fullpath, os.path.join(dirs[0],ns)
else:
# Выдадим предупреждение
logger.warn(“ file %s does not seem to be a valid mp3
file”,fullpath)
</code>

Полная распечатка этого небольшого скрипта представлена на
DVD данного номера Linux Format. Но будьте осторожны – скрипт не
завершен! Нельзя гарантировать, что он не испортит вашу музыкаль-
ную коллекцию! Особенно следует обратить внимание на проверку
символов в кодировке Unicode, нередко встречающихся в тэгах ID3v2
(недопустимых в тэгах первой версии). Также вы, возможно, захотите
обработать и файлы формата .ogg.

Здесь не доделано также множество проверок на ошибки. В случае
с тэгами в кодировке Unicode поможет структура try: ... except:; она же
пригодится и для других случаев (например, выяснении, как поступать
с музыкальными файлами без прав доступа на запись). Но я надеюсь,
что рассмотренный в статье пример показал вам, как просто создавать
полезные скрипты!

==== Будем резать! (врезка) ====
В Python используются индексы для «нарезания на кусочки» (иногда говорят «слайсинг»,
от англ. slicing) строк, списков и других типов
переменных. Пусть у нас имеется запись plop.
mp3; мы можем запросто извлечь из нее
любой нужный нам бит. Откройте терминал,
запустите Python для входа в интерактивный
режим и попробуйте следующие команды:

<code>
>>> string = ‘plop.mp3’
>>> print string[1]
l
>>> print string[:2]
pl
>>> print string [-0]
p
>>> print string [-1]
3
>>> print string [-4:]
.mp3
>>>
</code>

В последнем операторе print из строки выхватываются четыре последних символа.
Отрицательные индексы отсчитываются с конца строки, но будьте внимательны: -0 означает

==== Журналирование (врезка) ====
Небольшие скрипты часто нашпиговывают множеством выводов промежуточных данных на
печать, чтобы знать, что и как происходит. Это действительно удобно; но иногда хочется превратить строку с оператором печати в комментарий, потом снова её подключить, и т.д. Проще всего
в таком случае использовать встроенный в Python модуль ведения журнала! Он умеет выводить
сообщения и в консоль, но способен различать сообщения по значимости, и вы сможете гибко
регулировать количество выводов на консоль путём правки всего одной строки кода скрипта.
Добавьте этот модуль к списку импортируемых и впишите следующий код в начало вашего
скрипта:

<code>
logger = logging.getLogger(“pymusic”)
# Создать обработчик консоли
handler = logging.StreamHandler()
# Создать форматирование и настроить обработчик на его использование
formatter = logging.Formatter(“%(asctime)s - %(name)s - %(levelname)s - %(message)s”)
handler.setFormatter(formatter)
# Добавить обработчик к модулю ведения журнала
logger.addHandler(handler)
logger.setLevel(logging.WARN)
</code>
Часть этих штук смахивает на волшебство, и кое-кто считает модуль ведения журнала непостижимым, но на самом деле все очень просто. Если вы хотите узнать больше, документация
находится здесь: http://docs.python.org/lib/module-logging.html. Фактически, всё, что необходимо
знать – это набор стандартных команд для управления выводом сообщений в консоль.
Например, следующий код:

<code>
logger.warn(“ file %s does not seem to be a valid mp3 file”,fullpath)
</code>

выведет в консоль только сообщения, относящиеся к предупреждениям типа WARN или ниже
(порядок такой: Critical, Error, Warning, Info, Debug). Можно установить и собственные уровни, но
мы займёмся этим в другой раз...
то же самое, что и просто 0, а именно – начало
строки! (Индексы в Python нумеруются с 0.)

==== Форматирование (врезка) ====
Необходимость чёткого форматирования кода в Python многих ставит
в тупик, но это вполне простое и разумное требование. В частности,
отступы строк (посредством пробелов или табуляции) в блоке кода
должны быть одинаковыми, потому что в Python отступы являются
значимыми. Взглянув на код, вы не увидите фигурных скобок вокруг
любых операторов или блоков кода: Python распознаёт окончание блока по окончанию отступа. Это даёт сразу два преимущества: код становится гораздо удобнее для чтения, и не надо заботиться о вложенных
фигурных скобках!

LXF97:Первые шаги

2008-03-09T13:13:31Z

OWeRQ: Новая: == Органайзер: == ''Лекарством для недугов наших дней (кроме снижения затрат ископаемого топлива) была б...

== Органайзер: ==
''Лекарством для недугов наших дней (кроме снижения затрат ископаемого топлива)
была бы лучшая организация. '''Энди Ченнел''' – хозяин своего времени...''

Темп жизни, похоже, не собирается замедляться, и потерянное
искусство тянуть время становится, хм, все более потерянным.
Но так не обязательно должно быть. При содействии некоторых
стандартных программ Linux и правильного планирования все еще
возможно (по крайней мере, иногда) спихнуть на завтра то, что нужно
сделать сегодня. На самом деле, без этого не обойтись!

Ключом к продуктивным проволочкам является умение точно
представить, когда дело должно быть сделано, сколько времени оно
займет и что важнее. А ключевые типы программ, помогающие этого
добиться – Календарь и Список задач [To Do]. К счастью, в Linux есть
прекрасные программы для обоих рабочих столов, Gnome и KDE, в
лице Evolution и Kontact соответственно, но существуют также и кроссплатформенные пакеты, вроде Sunbird – и его дочернего проекта
Lightning, интегрированного в Thunderbird – а также целый диапазон
онлайн-решений, идущих ноздря в ноздрю с настольными соперниками. Ради простоты мы выбрали для данного урока Sunbird/Lightning,
но приведенные здесь методы подходят к практически любому мыслимому приложению, управляющему расписанием. Sunbird делает все
необходимое для контроля за нашим временем; мы создадим календари для задач, добавляя и редактируя события, установим напоминания,
подписавшись на сетевые списки событий, синхронизирумся с нашим
сетевым календарем и расставим приоритеты работ, настроив список
задач. Через страницу мы также покажем, как идти в ногу со временем
вдали от вашего Linux-компьютера при помощи новаторского (и очень
дешевого) органайзера Graphite.

Кое-что из этого основано на идее Getting Things Done (GTD) Дэвида
Аллена [David Allen] (www.davidco.com): как наиболее эффективно
управлять информацией и временем ''[в русском переводе: Д. Аллен
«Как привести дела в порядок. Искусство продуктивности без стресса»,
Вильямс, 2007 г.]''. И хотя вся GDT-«индустрия» полнится рекламной
шумихой и почти непознаваемым корпоративным сленгом, по сути она
выливается в несколько здравых идей, которые можно реализовать, не
прибегая к дорогому ПО, книгам или интенсивным семинарам.

=== Получаем программы ===
Для начала нам необходимы две программы, первая из которых – сама
Sunbird. На момент написания была доступна версия 0.5, на www.
mozilla.org/projects/calendar/sunbird/, она имеется на DVD этого месяца. Загрузив файл, дважды щелкните на архиве и распакуйте его куданибудь, где у вас хранятся приложения или двоичные файлы (в нашем
случае, это /home/downloads/имя_приложения). Затем сам архив можно удалить. Теперь просмотрите каталог Sunbird и найдите элемент с
именем Sunbird (вообще-то это скрипт) и дважды щелкните на нем.
Перед вами появится окно с выбором: показать файл, запустить его в
терминале или просто запустить. Выберите Запустить [Run] и подождите пока приложение запускается. При первом запуске вам предоставится возможность импорта данных календаря из других источников,
включая Evolution, а затем перед вами предстанет само приложение, по
умолчанию отображающее вид День. Абсолютно понятный набор других видов, доступный в верхнем меню окна, включает Месяц [Month]
и Неделю [Week].

Прежде чем двинуться дальше, сделаем на рабочем столе ярлык
для этого приложения и заставим его запускаться при каждой загрузке
системы – это удобный способ известить себя о насущных задачах на
день: календарь должен быть первым, что вы видите.

== Успеть все! ==
Итак, в Gnome щелкните где-нибудь на рабочем столе и выберите
Создать кнопку запуска... Добавьте соответствующее Имя, затем щелкните по кнопке Просмотреть... рядом с областью Команда. Перейдите к
элементу Sunbird, на котором вы щелкали ранее, и выберите его. Теперь
щелкните по кнопке с текстом Нет значка, выберите Просмотреть и
найдите каталог /Icon внутри каталога Sunbird. Выберите большую из
двух иконок и нажмите кнопку OK. Можете также добавить подсказку
для элемента, поместив текст в строку Примечание. Если иконка получилась слегка великоватой для вашего рабочего стола, то щелкните
на ней правой кнопкой мыши, выберите Растянуть значок, а затем
измените его размер, используя один из четырех квадратиков по углам
иконки. Теперь нажмите Система > Параметры > Сеансы и выберите
вкладку Запускаемые при старте программы. Нажмите Создать, задайте имя и, уже в последний раз, Просмотреть для перемещения в соответствующее место, чтобы выбрать приложение Sunbird.

Процедура для KDE весьма похожа, за исключением того, что
после правого щелчка при создании ярлыка на рабочем столе следует
выбрать Ссылка на приложение... (и далее то же). Чтобы приложение
запускалось автоматически, откройте ваш каталог в /home, выведите
скрытые файлы (Вид > Показывать скрытые файлы), перейдите в .kde/
Autostart и создайте в нем ссылку на приложение Sunbird.

Теперь, когда бы вы ни включили свой ПК, Sunbird в Gnome или KDE
будет запускаться автоматически, и вы точно будете знать, чему посвятите свой день – конечно, если позаботитесь о вводе этих данных.

Вторая необходимая нам программа также есть на DVD. Она назы-
вается Provider и позволяет Sunbird (или Lightning) осуществлять двустороннюю синхронизацию с календарем Google. Это значит, что если
вы обновите календарь Sunbird, то эти изменения попадут и в ваш сетевой календарь, и наоборот; а значит, открываете ли вы свои данные в
домашнем уюте или в интернет-кафе в Москве, вы всегда будете иметь
верную информацию под рукой. Последняя версия доступна на https://
addons.mozilla.org/en-US/sunbird/addon/4631. Однако если вы просто
щелкнете по кнопке Установить [Install Now], ничего не произойдет,
потому что расширение разработано для Sunbird, а ссылка работает
только в Firefox. Вместо этого щелкните на ссылке правой кнопкой
мыши и сохраните ее на вашем рабочем столе. Теперь откройте Sunbird,
выполните Инструменты > Дополнения и внизу слева нажмите кнопку
Установить... Откроется стандартный диалог открытия файла, и вы
сможете выбрать в нем загруженный XPI-файл. По завершении установки понадобится перезапустить Sunbird.

=== Добавляем содержимое ===
Итак, мы справились с установкой, но пока данных нет, проку от этого
мало. Первое, что мы добавим – праздники своей страны: это легко,
благодаря тому, что web-сайт проекта в разделе Docs & Extras имеет
набор календарей праздников. Отыщите ссылку на вашу страну и сохраните файл на свой жесткий диск. Вернитесь в Sunbird, выполните Файл
> Открыть календарь... [File > Open Calendar File...] и переместитесь к
только что загруженному файлу. Теперь, выбрав вид Месяц, вы должны увидеть, что календарь заселен различными событиями. Можете
отключить эти события, перейдя на вкладку Календари [Calendars]
(слева от главного окна) и сняв галочку напротив RussiaHolidays.
Поскольку Sunbird использует распространенный формат файловкалендарей ICS, можно загружать из сети всевозможные варианты –
например, игры сборной Манчестера на сезон–2007/2008, и это будет
отдельный календарь внутри приложения.

Собственные события можно добавить в календарь, дважды щел-
кнув на дате или во временной секции любого из видов и добавив
соответствующую информацию. Каждое событие должно иметь дату,
время и продолжительность (если только это не событие на весь день),
и выбранный Календарь (то есть частью какого календаря оно является). Среди других опций, пригодится флажок Повторять, который
также позволяет повторить событие согласно определенному шаблону,
если, например, надо учесть событие, происходящее в 10:00, но только по будням и только до 22 декабря. После определения события оно
тут же появится в соответствующем окошке, подкрашенное цветом,
выбранным для данного календаря. Вы можете изменить детали события, дважды щелкнув на нем; или, если необходимо изменить только
дату (или время в виде День), можете перенести выбранную секцию в
другое место.

Для грамотного управления временем необходимо изучить две
основные концепции: разделение и приоритет. Примером первой является собрание всех российских праздников в один календарь Sunbird.
Эта информация может быть включена или выключена, то есть при
желании вы можете полностью ее игнорировать, пока она снова не
понадобится. Вторая связана с использованием списков задач с приоритетами – Sunbird их тоже поддерживает, но мы воспользуемся сетевым сервисом: он более гибок и прекрасно интегрируется с Sunbird.

Предположим, в вашей жизни есть три главных приоритета: семья,
работа и дела общественные; последнее – в форме заведования школой. Надо также отслеживать важные даты релиз-цикла Fedora. На все
это требуется пять календарей, включая уже имеющийся календарь
российских праздников. Конечно, можно сгрести все эти данные в один
календарь, но смысл отдельных календарей в том, что вы можете предвидеть свою жизнь, если хотите – то в виде баланса работа/жизнь, на
месяц вперед и, если необходимо, полностью «отключить» какую-то из
линий, если требуется сосредоточиться на другом.

Первым делом надо переименовать домашний календарь по умолчанию – Мой календарь: он идеально подойдет как календарь обще-
ственных мероприятий, поскольку к нему не нужен удаленный доступ.
Щелкните правой кнопкой мыши на Моем календаре, выберите
Свойства (или дважды щелкните на нем) и введите новое имя. Здесь
вы можете также задать новый цвет календаря.

Для создания нового календаря, щелкните правой кнопкой мыши
в панели календарей (слева в главном окне) и выберите Новый календарь... или просто выполните двойной щелчок где-нибудь на этой
панели для запуска мастера нового календаря. Вначале вам предложат
два варианта: календарь на вашем компьютере или в сети? Первый
просто хранится на вашем компьютере (так же, как переименованный Общественный календарь), а второй для получения информации
соединяется с календарем в Интернете; однако для доступа или изменения данных сетевого календаря не обязательно подключаться к сети,
поскольку Sunbird создаст локальное зеркало на то время, пока вы
отсоединены. Вы можете обновить все позднее, щелкнув правой кнопкой мыши на календаре и выбрав Обновить удаленные календари или
используя комбинацию клавиш Ctrl+R.

Нас интересует возможность работать с нескольких разных компьютеров, но так, чтобы иметь доступ к данным и в отсутствие сети,
поэтому создадим сетевой календарь. На самом деле, сперва мы подключим существующий календарь Google, а потом – календарь в формате iCal. Это означает, что нам не придется вновь вводить кучу данных
или, что более важно, потерять их, если жесткий диск выйдет из строя
или вор-линуксофил стырит ноутбук LXF: оба аспекта очень важны при
решении вверить свои данные какому-либо устройству.

Чтобы внести информацию в Sunbird, вначале войдем в службу
Google Calendar и выберем календарь, к которому собираемся подключиться. Как и в Sunbird (и практически везде), список доступных
календарей отображается слева. Щелкните на стрелке рядом с именем календаря и выберите Calendar Settings [Настройки календаря].
Интересующий нас раздел внизу окна справа и озаглавлен Private
Address [Личный адрес]. Щелкните правой кнопкой мыши на кнопке XML и выберите Copy link location [Скопировать ссылку]. Теперь
вернитесь в Sunbird и запустите мастер нового календаря. Выберите
календарь В сети и опцию Google Calendar и, по запросу, вставьте скопированный URL из буфера обмена при помощи Ctrl+V. Нажмите Далее.
Теперь вам предоставляется возможность задать календарю имя (мы
выберем Работа), а также цвет отображения. Цвета очень важны с
точки зрения организации: они сразу же наглядно покажут, чем будет
занят ваш день, неделя или месяц и насколько вы будете заняты; так
что выберите цвет, некоторым образом соответствующий целям календаря, и убедитесь, что отличие в оттенках каждого из них бросается в
глаза. В следующем окне необходимо ввести детали для входа на сервер и выбрать, следует ли сохранить эти детали, чтобы календарь мог
обновляться автоматически. Когда вы дойдете до конца, данные будут
загружены, и, как по волшебству, появятся в Sunbird. Теперь сделайте
то же для остальных ваших личных календарей. Поскольку мы установили для Sunbird модуль расширения Provider, то любые изменения,
сделанные нами в календарях, связанных с сервисом Google, будут
отражены в версии, размещенной в сети.

Далее, добавим динамический календарь событий, сосредоточенный на проекте Fedora: вновь запустим мастера нового календаря
и выберем опцию В сети и формат iCalendar (ICS). Календарь находится на webcal://fedora.redhat.com/participate/schedule/fedora-project.
ics, так что вставьте этот URL в строку Адрес и нажмите кнопку OK.
Замечательно то, что если некий пользователь обновит календарь
Fedora, он будет синхронизирован с вашим, так что у вас всегда будет
свежая информация. Выше главного окна календаря расположен список встреч: это просто список всего, что вам предстоит, и поскольку
он отражает содержание календаря ниже, то вы можете включать и

=== Что за дела! ===
Мы заготовили несколько календарей, предоставляющих долгосрочный обзор того, что нас ждет – и можем сконцентрироваться на
задачах дня, а для этого необходим Список задач [To Do list]. Sunbird
имеет окно со списком задач, но бывает удобнее разделить ваше расписание на два вида (долгосрочное и текущее), чтобы, работая над
непосредственными задачами, вы не отвлекались бы на то, что ждет
вас за углом.

Для управления нашими списками воспользуемся сервисом под
названием Remember The Milk [«Не забудь купить молока»] (www.
rememberthemilk.com). Это сетевое приложение позиционируется как
«список напоминаний о покупках», но фактически это Управление задачами/Список задач промышленного уровня, и оно прекрасно подойдет
для наших попыток Привести Дела В Порядок. Мы выбрали Remember
The Milk (RTM), а не другой сетевой сервис из подобных Списков задач
по той причине, что RTM позволяет создавать различные списки, способные отражать пометки о событиях в наших календарях. К тому же
последняя версия программы работает с Google Gears (более подробно – см. http://gears.google.com), а значит, вы сохраните доступ к редактированию ваших списков, будучи вне сети; данные затем будут обновлены при очередном подключении к Интернету.

Прежде всего, надо зарегистрироваться на сервисе и, что не обязательно, загрузить и установить программу Google Gears, запускаемую
из XPI в Firefox. Зарегистрировавшись и войдя, щелкните на ссылке
Settings [Настройки], расположенной справа вверху главной страницы
RTM. Теперь выберите вкладку Lists [Списки]: здесь вы можете опревыключать его части, используя флажки в списке календарей слева.
делить сколь угодно много своих списков. Щелкните на кнопке Add List
[Добавить список] и дайте списку имя. При желании быть действительно суперсобранным, можете создать список для каждого дня недели,
чтобы знать, что вы хотели выполнить в каждый 24-часовой период,
плюс список Будущее для того, что произойдет чуть позже. Или просто
следуйте схеме, используемой для вашего календаря. Каким бы способом вы ни решили организовать ваши списки, RTM разместит их в
алфавитном порядке, а если вы хотите иного упорядочения, придется
добавить к вашим спискам числа (01, 02, 03 и т.д.). Покончив с этим,
перейдите на страницу Tasks [Задачи] (ссылка справа вверху) – вы
увидите, что каждый список имеет свою вкладку; есть еще две стандартные вкладки с именами Inbox [Входящие] и Sent [Отправленные],
к которым мы сейчас перейдем.

Чтобы начать, щелкните на одной из вкладок. Метод добавления
задачи тот же, что и при создании различных списков: выберите Add
Task [Добавить задачу], введите имя задачи и нажмите ввод. По умолчанию, задачи будут появляться в порядке их введения, но вы можете
изменить этот порядок, установив некоторым из них приоритеты – это
один из фундаментальных аспектов серьезной организации, достойный применения. RTM имеет четыре настройки приоритетов: 1, 2, 3 и
none [нет]. Для придания задаче приоритета, выберите ее, используя
флажок слева от имени задачи, а затем в выпадающем списке над
задачами укажите соответствующий приоритет. Задача при этом подсветится и, в зависимости от выбранных вами настроек, может также
изменить свою позицию в списке. Высокоприоритетные элементы
всплывут к верху краю списка, элементы без приоритета останутся
внизу. Вы можете также повысить или понизить приоритет области
задач, выбрав все те, что нужно изменить, и применив к ним пункт
списка Move Priority Up... [Повысить приоритет...]. При этом приоритет
3 у задач изменится на 2, а 2 изменится на 1. События без приоритета
автоматически получат приоритет 3.

Это облегчает управление приоритетами в течение дня. Завершив
задачу с высоким приоритетом, вы можете выбрать ее и пометить как
Complete [Выполнено], а затем выбрать следующую и увеличить ее
приоритет на 1, чтобы знать новую первоочередную задачу.

Вы могли заметить, что задачи по умолчанию не связаны с датой;
добавить ее и можно, и несложно. Сперва выберите задачу, установив
флажок, а затем перейдите в раздел справа от списка задач. На вид это
просто информационный список, но все записи в нем можно редактировать, и если вы щелкнете на тексте рядом с записью Due: [Срок],
то сможете добавить информацию о сроке выполнения задачи. RTM
хватает ума, чтобы проверить и реализовать ваши намерения; например, если вы введете срок как ‘next tuesday’ [следующий вторник], он
автоматически введет за вас дату, а если вы укажете только время, он
сочтет, что вы имели в виду «сегодня», если время еще не прошло;
иначе он впишет его на «завтра». Вы можете также установить опцию
повторения (она работает так же, как и в календаре), добавить предположительное время завершения, поместить тэги для категорий поверх
уже имеющихся и даже добавить URL, если, например, задача связана
с неким web-сайтом или документом в сети.

В добавление ко вкладке Task [Задача], имеется также опция Notes
[Заметки] – это небольшая, автоматически сохраняющаяся текстовая
область, где можно внести дополнительные детали конкретной задачи. Все эти детали окажутся под рукой, когда вы выберете задачу из –
весьма мощное подспорье. Задачи можно также добавлять в список по
электронной почте, SMS или, если вы хотите приобщиться к Web 2.0,
даже через учетную запись Twitter.

=== Полный цикл ===
Итак, мы организовали наше расписание в Sunbird и справились с организацией управления текущими задачами посредством Remember The
Milk. Настало время небольшого объединения мыслей и связей: соединим обе службы вместе. RTM имеет возможность вывода вашего списка задач – по крайней мере, тех, у которых есть дата завершения – в
виде iCal-файла, то есть мы можем подписаться на этот URL при помощи Sunbird и получить автоматическое появление задач в календаре.
Стандартная система RTM выводит каждый список в виде отдельного iCal-файла, но не худо бы собрать их в один синхронизированный
файл. Так что вновь перейдите на страницу Settings [Настройки] и
выберите вкладку Info. Здесь вы найдете адрес электронной почты для
пересылки задач в ваш список, адрес ленты Atom (и сможете просматривать ваш список задач в читалке RSS), а также два адреса, которые
можно добавить в строку Адрес в окне нового календаря Sunbird.

Здесь есть две опции. Во-первых, возможен экспорт списка задач в
виде списка, но он поддерживается немногими программами. Лучший
(да и единственный) выбор для Sunbird – заставить RTM экспортировать списки как события. Щелкните правой кнопкой на URL с пометкой
iCalendar Events Service (All Lists) [Служба событий iCalendar (Все списки)] и выберите Copy Link Location [Копировать ссылку]. Теперь вернитесь в Sunbird и вставьте эту информацию в строку Адрес нового календаря. Задайте новому календарю имя и цвет, и ваши события перекочуют в Sunbird. Однако помните, что в отличие от календаря Google, к
которому мы подключались ранее, это езда в один конец: изменение
даты завершения задачи в Sunbird не отразится в списке RTM.

Хотя хорошее управление временем не снизит число распечаток
и не укоротит бессмысленные споры ваших детей, оно может оказать
положительное влияние на ваш уровень стресса и улучшить отношения
с семьей и коллегами. И благодаря осведомленности о том, что мне
следует делать и когда, я выкроил 20 минут на эффектное завершение
статьи. А лучше посижу немного в саду...

==== КПК-органайзер Graphite (врезка) ====
Все еще существуют такие места и времена,
когда у вас нет доступа к вашим любовно построенным календарям и спискам задач. Для
таких случаев, органайзер Graphite – прекрасный инструмент внесения данных, готовых для
синхронизации с вашими календарями и списками задач при первой возможности. Такие
продаются в любом приличном магазине канцтоваров и в большинстве супермаркетов, причем во всевозможных видах: прошитые, на
спиральке и клеенные. На пару с маленьким
карандашом, органайзер можно легко извлечь
и использовать практически везде, даже там,
где суеверные туземцы подозревают, что электричество – это мстительный злой дух.
Основные принципы обращения с подобными
штуками – выбирать их малого формата,
использовать по листку на день и, вычеркнув
все на листке, тут же его выбрасывать, чтобы
верхним всегда был «сегодня» или «просрочено». Да, и не забывайте о взаимном обмене
событиями между органайзером и вашим
списком задач (исключительно нудное занятие).

LXF97:Paragon NTFS

2008-03-09T12:53:15Z

OWeRQ:

== Paragon NTFS for Linux 6.0 ==
''Нужна запись на жесткие диски Windows XP или Vista из-под Linux?
'''Нейл Ботвик''' тестирует единственное потенциальное решение
с поддержкой сжатия NTFS.''

Пользуясь открытым ПО, мы принимаем как должное даваемую им свободу. Здесь нет тайн, и программы
легко срабатываются друг с другом: ведь их
внутренние механизмы показаны в исходном
коде. Если нужен доступ к файловой системе
Linux из Windows, достаточно лишь установить драйвер – вся информация, необходимая для его написания, открыта и доступна.
Попробуете сделать наоборот – совсем другая
история. В ядро Linux встраивается ограниченная поддержка файловой системы NTFS,
ограниченная в том смысле, что безопасным считается только чтение с этой системы.
Альтернатива – модуль NTFS-3G FUSE, предоставляющий доступ и на чтение, и на запись.
Paragon сработал еще одну, коммерческую
альтернативу, но по плечу ли ей заставить вас
раскошелиться (а заодно и поступиться принципами свободного ПО)?

Существует две версии NTFS for Linux:
персональная, о которой пойдет речь в
нашей статье, устанавливает лишь драйвер
файловой системы без дополнительных
инструментов. Профессиональная версия
оснащена инструментами для создания,
изменения размеров, архивирования и других операций с NTFS-разделами из-под
Linux. Обе версии могут похвалиться Live
CD для доступа к NTFS-разделам, включая
возможность резервного копирования данных на CD или DVD.

Как же работает программа? Прилично, и
очень быстро. Файловая система устанавливается в качестве модуля ядра, поэтому перед
инсталляцией необходимо иметь исходный
код ядра и среду для компиляции, чего по
умолчанию в большинстве дистрибутивов нет,
но все необходимые компоненты присутствуют в стандартном репозитории. Установив их,
инсталлировать программу нетрудно: достаточно распаковать zip-архив и запустить sh
install.sh (не верьте документам, советующим
использовать ./install.sh, поскольку бит ‘x’ на
нем не установлен). Инсталлятор формирует
и инсталлирует модуль файловой системы,
затем разыскивает NTFS-разделы и добавляет
их в /etc/fstab. Есть возможность автоматического монтирования таких разделов при загрузке. Графического инсталлятора нет, а базовые
инструкции, пожалуй, чересчур подробны, но
запуск инсталляционного скрипта – это все,
что вам нужно сделать.

Будучи установленной, файловая система
монтируется так же, как и любая другая, но,
вследствие различий с NTFS, получить такие
же права доступа и владения, как в Linux,
не получится. Вместо этого предоставляются
параметры монтирования с указанием владельца, группы и прав доступа по умолчанию
для файлов, совершенно так же, как с встроенными в ядро файловыми системами FAT.

==== Производительность (врезка) ====
Мы пробовали запустить тестовые программы bonnie, bonnie++ и
iozone, но они не работают с NTFS For Linux, и это показывает, что
некоторые важные функции файловой системы упущены. Но вряд ли
кто-нибудь заведет базу данных или почтовый сервер на NTFS-разделе, да и сверхскоростное массовое копирование/создание файлов
вряд ли понадобится. Так что мы обошлись тестами попроще. Они
состояли из копирования двух наборов файлов в обоих направлениях.
Первый набор состоял из 4 ГБ больших видеофайлов, чтобы оценить
максимальную скорость копирования. Второй набор, из 713 МБ малых
файлов (49900 на два «ядерных» дерева), показывал способности
обращения со сложными файловыми структурами при сравнительно
малом объеме передаваемых данных. NTFS For Linux оказалась медленнее NTFS-3G в первом случае, при копировании файлов большого
объема, и быстрее – во втором, при наличии сложной системы файлов. Полученные цифры приводятся ниже.

{|
|
|NTFS for Linux
|NTFS-3G
|-
|Запись 4 ГБ больших файлов
|80 секунд
|128 секунд
|-
|Чтение 4 ГБ больших файлов
|207 секунд
|108 секунд
|-
|Запись 713 МБ малых файлов
|99 секунд
|806 секунд
|-
|Чтение 713 МБ малых файлов
|105 секунд
|545 секунд
|}

=== Давление сжатия? ===
83-страничное руководство, доступное на сайте Paragon (но не включенное в загружаемый
архив) покрывает вопросы инсталляции и различные параметры монтирования файловых
систем NTFS, причем речь идет в основном
об инструментах профессиональной версии.
Существенное отличие от NTFS-3G – обращение со сжатыми файлами. Это файлы, сжатые
на уровне файловой системы, а не обычные
zip-архивы. Хотя читать такие файлы могут
многие файловые системы, записывать в этот
формат умеет лишь NTFS for Linux – и если у
вас сжатая NTFS, ваш выбор уже сделан. LXF

LXF97:MailEnforcer 3.0

2008-03-09T12:51:40Z

OWeRQ: Новая: == MailEnforcer 3.0 == ''На рынке ПО для предприятий затевается нечто действительно серьезное, если '''Грэм Морри...

== MailEnforcer 3.0 ==
''На рынке ПО для предприятий затевается нечто действительно серьезное, если '''Грэм Моррисон'''
решился вставить в обзор выражение «проталкивать».''

Безопасность Linux общеизвестна; главным образом потому-то мы им и пользуемся. Но это видимое преимущество
лишь сейчас начинает влиять на мир бизнеса:
сразу несколько компаний готовят продукты, призванные протолкнуть Linux на широкий рынок. Устройство Yoggie Gatekeeper Pro,
которое мы рассматривали в LXF95 – яркий
тому пример. Это встраиваемый Linux-компьютер, установленный на USB-брелок, для
фильтрации и защиты интернет-данных – при
этом неважно, под какой ОС работает компьютер-хост. MailEnforcer имеет сходное назначение, только масштаб крупнее. Продукт поставляется предустановленным на сервер по вашему выбору либо в виде комплекта DVD/CD для
инсталляции на имеющееся оборудование, с
целью обеспечения безопасности электронной
почты на уровне предприятия. После установки программа занимает место между почтовыми серверами и Интернетом, проверяя сообщения на соответствие строгим критериям, а
заодно регистрируя все сообщения, создавая
отчеты и посылая предупреждения.

=== Мудрость Oracle ===
Для установки MailEnforcer на наш сервер Athlon
64 X2 мы взяли DVD-версию. Фактически, устанавливается 64-битная версия Oracle Enterprise
Linux, и это был первый раз, когда данный
отпочкованный Oracle от Red Hat дистрибутив
повстречался нам в живой природе. Литература
о продукте утверждает, что глубоких познаний
Linux не требуется, и это соответствует истине – по крайней мере, во время инсталляции:
даются точные указания о том, что устанавливать, какие службы включить (есть только SSH
и SMTP) и как сменить пароль суперпользователя. Все остальное делается через web-интерфейс, доступный после инсталляции. Однако
мы не рекомендуем слепо полагаться на Linux,
не обладая хотя бы минимальными навыками.
Средний администратор без опыта работы в
Linux может споткнуться, даже делая такие
простые вещи, как смена IP-адреса сервера –
особенно если инсталляция не включает X11.

Web-интерфейс – облицовка либо для
встроенного Java-апплета, либо для загружаемого приложения Java Web
Start (последнее работает
на нашей машине немного
быстрее). Успешным был
и опыт с Blackdown Java –
единственный метод получить 64-битную версию
Web Start. Да и любая другая 32-битная инсталляция
Java (1.4 и 1.5) не должна
вызвать особых проблем. Во время работы
внутри MailEnforcer крутится столько страниц,
что ими можно было бы наполнить мифическую Вавилонскую библиотеку. Это пугает
до тех пор, пока вы не уясните, как все-таки
работает эта система. MailEnforcer напоминает web-прокси, а чтобы поместить программу между вашими почтовыми клиентами и
серверами (как правило, Microsoft Exchange
или Sendmail), ее нужно настроить. В малом
окружении MailEnforcer можно использовать
даже как самостоятельный POP-сервер, установив простые настройки и включив пользователей во внутреннюю группу – кстати, это
неплохая возможность протестировать систему перед началом ее серьезного использования. Правильно настроенный, MailEnforcer
должен быть прозрачен для конечного пользователя, проявляясь разве что в извещениях
о блокировке сообщения, которое нужно както вызволять.

=== Изобилие настроек ===
Сказать, что MailEnforcer легко настраивается – значит, сказать очень мало. Под собственные нужды здесь можно перекроить буквально все. Характерный пример – фильтры
сканирования почты, имеющие более сорока
параметров настройки (и все включены по
умолчанию). Среди них проверка коммерческим (Kaspersky) и открытым (ClamAV) антивирусами, доступ к различным онлайн-базам
данных по фишингу и спаму, черные списки
DNS, оптическое распознавание изображений и многие другие тесты. Мы заваливали
программу сотнями писем из наших коллекций спама, а MailEnforcer добросовестно
блокировал их или помечал как подозрительные. Страница обзора статистики, кроме
своего прямого назначения, позволит вам
засечь необычно высокую почтовую активность и направит на ваш электронный адрес
более подробные отчеты. Вдумчиво комбинируя подразделения и группы, можно добиться
осуществления любой мыслимой политики,
а также переложить часть бремени администрирования, используя микроменеджмент.
Продукт легко масштабируется и подходит как
для малых/средних предприятий, так и для
сравнительно крупных организаций. Подобной
программы для Linux мы до сих пор просто не
встречали. LXF

LXF97:Yellow Dog PS 3

2008-03-09T12:48:10Z

OWeRQ: Новая: == Yellow Dog Linux 5.0.2 == ''Из-за перехода Apple c PowerPC на процессоры Intel будущее Yellow Dog заволакивается туманом. '''Грэ...

== Yellow Dog Linux 5.0.2 ==
''Из-за перехода Apple c PowerPC на процессоры Intel будущее Yellow Dog заволакивается туманом.
'''Грэм Моррисон''' видит (маловероятного) спасителя в PlayStation 3 от Sony.''

Когда Apple перешла на архитектуру
Intel, сразу же встал вопрос о выживании PowerPC-ориентированных
дистрибутивов вроде Yellow Dog Linux (YDL)
без своей главной пользовательской базы.
Но процессор PlayStation 3 (PS3) Cell (производная от PPC), вкупе с решением Sony оставить возможность установки альтернативной
ОС, открывают двери для Linux. Есть версии
Ubuntu и Fedora, специально собранные для
PS3, но YDL была здесь с самого начала.

=== Другая ОС ===
Понадобятся обычные USB-клавиатура и
мышь – мы успешно опробовали несколько разных устройств. После инсталляции
Linux игровой контроллер PS3 поддерживается через USB-порт, но только как джойстик.
Проблема инсталляции Linux на PS3 состоит
в том, что приходится переформатировать и
заново разбивать жесткий диск из главного
меню приставки – инструменты дистрибутива
для этого использовать невозможно, так как
Sony ограничила прямой доступ и к жесткому
диску, и к графической аппаратуре. Видимо,
фирма опасается посягательства Linux-разработчиков на ее мировое господство в игровой
сфере. Есть угроза потерять весь загруженный
контент, сохраненные игры, музыку, видео и
фотографии, если только предварительно не
сделать резервную копию. К счастью, функция резервирования и восстановления в PS3
развита хорошо: приятно видеть, что не все
потеряно, обретая прежнюю консоль после
переформатирования. Сетевая учетная запись
PlayStation Network сохраняется, на месте и
настройка беспроводного доступа, и другие
настройки, сделанные вами ранее.

Нужно установить загрузчик YDL с DVD
(достаточно вставить диск и выбрать «Install
Other OS» в системном меню PS3) и сменить
ОС приставки по умолчанию, чтобы подобие
загрузчика Sony изменилось на Grub или LILO.
Мы обнаружили, что в случае возникновения
каких-либо проблем, достаточно выключить
питание консоли, затем удерживать кнопку
питания в течение пяти секунд – и стандартная
конфигурация Sony полностью восстановится.
Инсталляция продолжительна, занимает свыше 90 минут – хотя инсталлятор и уверяет, что
25 минут для установки вполне достаточно.

=== Недоуправление пакетами ===
Набор ПО в YDL довольно скуден. Вы получаете Firefox, OpenOffice.org и Eclipse IDE,
плюс пригоршню игр Gnome, и все это искусно вплетено в рабочий стол Enlightenment.
Запущен и OpenSSH, а VNC держится наготове
на случай, если вам захочется использовать
ТВ. Менеджер пакетов YUM инсталлирован,
поэтому нетрудно добавить дополнительные
репозитории и загрузить все необходимые
пакеты. Удобная среда с несколькими API
для многопоточной Cell-разработки выглядит
и работает гладко, а сравнительно небольшое потребление памяти E17 (у PS3 только
256 МБ RAM) сохраняет отзывчивость системы. Правда, если запустить программу с чуть
большими потребностями по памяти, рабочий стол начинает тормозить. Firefox, например, запускается 8 секунд, а после запуска
еле тащится. Аппаратные ограничения Sony
вынуждают Linux-дистрибутивы применять
для графического вывода фрейм-буфер, не
извлекая никакой выгоды из мощной аппаратуры Nvidia. Но не все так плохо, как может
показаться – например, полноэкранное видео
со стандартным разрешением работает без
проблем. И все же графическое ускорение
могло бы помочь YDL выйти на «большую
дорогу» и получить более широкое признание.

=== Свойства навскидку (врезка) ===
'''Пакеты YUM'''

Добавьте собственные
репозитории для установки
новых приложений – и ваша PS3
превратится в полноценный
медиаплейер.

'''Специально для PS3'''

Инсталляция ПО и поддержка
сети специфичны для PS3, а
значит, заставить заработать
функции вроде беспроводного
доступа совсем несложно.

LXF97:Google Desktop

2008-03-09T12:43:32Z

OWeRQ: Новая: == Google Desktop 1.0 == ''Страсти по настольному поиску отбушевали двенадцать месяцев назад. '''Грэм Моррисон''' с...

== Google Desktop 1.0 ==
''Страсти по настольному поиску отбушевали двенадцать месяцев назад. '''Грэм Моррисон''' считает,
что Google припозднился с предложением для Linux.''

Спустя почти три года после выпуска
первоначальной версии для Microsoft
Windows и на два месяца позже версии для Apple OS X, Google Desktop наконец-то
пришел в Linux. Слово «desktop» в названии
несколько двусмысленно. Google Desktop –
только поисковый инструмент, способный
заменить Kat [ныне Strigi, – прим.ред.] в KDE
или Beagle в Gnome, но никак не рабочий стол
KDE или Gnome. Хотя программа далеко не
бесполезна: до сих пор нам не сильно везло
с приличными поисковыми инструментами
для Linux. Несмотря на потенциальную полезность, они либо занимают под свой индекс
весь жесткий диск, либо отъедают солидные
куски оперативной памяти, либо полностью
блокируют компьютер после нескольких дней
использования. Хотелось бы встретить работоспособную версию.

=== 64 – быть? ===
Google предоставляет 32-битные двоичные
пакеты в форматах Deb и RPM для большинства Linux-дистрибутивов. Обещана 64-битная версия, хотя мы без особого труда установили 32-битный вариант на нашу 64-битную машину. Затем остается вручную запустить программу командой gdlinux – на панели
инструментов появляется маленький значок
Google Desktop, и начинается важнейший процесс индексирования. Кажется, что он длится
целую вечность. Индекс формируется лишь во
время простоя компьютера, поэтому прошло
несколько дней, прежде чем 81361 файлов на
нашей машине были полностью проиндексированы, что составило около 7 часов чистого
времени обработки. Подобно Kat или Beagle,
поиск Google Desktop проникающий: просматривается и анализируется не только имя файла и его местонахождение, но и содержание,
причем каждый тип файлов требует особой
обработки. Поддерживается множество различных форматов с уклоном в Linux: документы OpenOffice.org, стандартные почтовые
директории, Thunderbird, PDF, Ogg Vorbis, mp3
и истории браузеров. Тот, у кого есть почта
на Google, может включить в индекс учетную
запись Gmail, интегрировав таким образом ее с
рабочим столом. Удивляет лишь полное отсутствие поддержки формата Microsoft Office.

=== Встроенный сервер ===
Есть два способа начать поиск. Можно дваж-
ды нажать клавишу Ctrl, и откроется малень-
кий поисковый инструмент, а можно вызвать
новую домашнюю страницу Google из панели.
Поисковый инструмент интуитивно понятнее и
хорошо интегрируется в рабочий стол, подобно Beagle или Spotlight на OS X. Во время набора слов запроса результаты появляются ниже
поля ввода. Нажатие Enter выводит более
подробные результаты поиска в отдельном
окне браузера. Выглядит все это совершенно
так же, как онлайн-поиск Google, который все
мы знаем и любим, включая краткий конспект
по содержанию результата каждого запроса.
Google утверждает, что никакие данные с персональных серверов на его собственные серверы не поступают. Типы файлов обозначаются маленькими значками, а щелчок на одном
из файлов в списке найденных открывает его
в назначенном по умолчанию приложении.

Все это работает безупречно, без всяких проблем с производительностью, которыми страдают «родные» Linux-приложения. Но
вывод web-браузера не очень хорош с точки
зрения интеграции в рабочий стол – вдобавок
не работает опция ИЛИ – и возникает неприятное чувство, что это скорее циничная попытка
Google навязать пользователю зависимость
от своей поисковой технологии, чем действительно полезное Linux-приложение. Windowsверсия обладает виджетами, чья функциональность схожа с Dashboard/SuperKaramba,
что гораздо удобнее. Хотелось бы увидеть
нечто подобное и в Linux. А пока это только очередной настольный поисковый инструмент. Пускай и работоспособный...

==== Свойства навскидку (врезка) ====
'''Интеграция'''

Дважды нажмите клавишу Ctrl –
поисковик Google откроется и
заполнит свое окно результатами поиска по вашему запросу.

'''Проникающий поиск'''

Google Search читает содержание файлов многочисленных
типов и добавляет результаты
чтения к своему индексу для
удобства последующего поиска.

LXF97:eSys PC

2008-03-09T12:37:35Z

OWeRQ: Новая: == eSys ePC basic == ''Данный ПК – еще не ноутбук за $ 100, но он доказывает, что концепция реализуема. ''Ник Вейч'' п...

== eSys ePC basic ==
''Данный ПК – еще не ноутбук за $ 100, но он доказывает, что концепция реализуема.
''Ник Вейч'' проверяет, может ли такая удача быть правдой...''

Ну что можно купить за 280 долларов?
Кусок PlayStation 3? 736 консервных
банок фасоли? Четыре подписки на
лучший в мире журнал о Linux? А настольный
компьютер с предустановленным Linux – не
хотите? Компания eSys – известный производитель систем, которые специалисты
по маркетингу называют «доступными», в
диапазоне от самых простых до умеренно
«навороченных». Наша модель – простей-
шая из простых – дешева до предела. Но:
дешевка ли?

Качество изготовления – хоть куда. Чашку
кофе можно ставить сверху без опаски. И
хотя корпус – гадкий midi-tower серебристого
пластика от магазина бытовой техники High
Street, свое дело он делает. Предусмотрены
свободные отсеки для дополнительного оборудования (отрада самоделкиных), несколько
USB- и аудио-портов спереди и обычный частокол выводов сзади, включая стандартный
VGA-разъем для монитора.

В комплект входят мультимедиа-клавиатура и мышь, а вот на монитор придется раскошелиться. Найдите такой, чтобы работал со
стандартным VGA-входом – впрочем, многие
ЖК-дисплеи это до сих пор умеют.

По части графики, материнская плата, на
которой собрана система, оснащена встроенным графическим чипсетом VIA, но это

не есть хорошо. Конечно, VIA позаботилась
о поддержке Linux на своем оборудовании,
но лучший результат зачастую достигается
при использовании свободных драйверов, не
полностью поддержанных VIA. Однако даже
проект Openchrome, всеобщая палочка-выручалочка, на время написания статьи не поддерживал данный чипсет. Винить eSys особо не за что, но, честно говоря, компания
могла бы подобрать материнскую плату от
Intel с интегрированной поддержкой графики.
Досадно осознавать, что потенциал аппаратуры используется не полностью. Стоит, правда,
заметить, что улучшенная поддержка графики
могла бы повлиять разве что на качество воспроизведения фильмов – того, кто ищет мощную графическую станцию, наша машина вряд
ли заинтересует.

=== Ubuntu навсегда ===
В комплект входят клавиатура и мышь. Оба
устройства оснащены разъемами PS/2, и это
радует. Клавиатура выглядит вполне солидно,
есть все функциональные клавиши, а сверху
еще и панель медиакнопок. Удивительно, но
все они (ну, почти все) исправно работают!
Разве не здорово, что можно изменить громкость или запустить браузер без мороки с X-настройками или lineak?

Менее удивительно то, что сборщики eSys
EPC выбрали в качестве системы для установки Ubuntu (между прочим, компьютер снабжается сопроводительным диском с драйверами
VIA, хотя толку от него мало, ведь на нем нет
специальных Linux-драйверов). Это уже тенденция, и с учетом того, что Dell тоже собирается ставить Ubuntu, выбор явно неплох. Не
могут же ошибаться сразу несколько миллионов пользователей, верно?

Разочаровывает, однако, что это голая инсталляция Ubuntu. Похоже, произошло следующее: Ubuntu (речь идет о 6.06 LTS) установили
на компьютер, использовав стандартное имя
пользователя и пароль (кстати, они есть на
стикере на боку коробки!), затем полученный
образ залили на жесткие диски всех новых
компьютеров. Зная это, нетрудно предугадать
последствия подобной установки Ubuntu.

Например, если вы задумали подарить
такой компьютер племяннику на Рождество,
готовьтесь к продолжительным телефонным
переговорам. После первой загрузки и входа в
систему пользователь получает стандартный,
пустой рабочий стол Ubuntu: ни на экране,
ни в коробке нет никаких сведений о том, что
делать дальше. Невольно возникает идея сразу же сменить пароль и/или настроить новую
учетную запись!

Но это не единственная проблема. Конечно,
бывалый линуксоид запросто добьется правильной работы, установив дополнительные
пакеты, но ведь большинство покупателей
будут новичками. Так вот, когда они запустят Firefox и набредут на какой-нибудь сайт с
Flash-эффектами, обнаружится, что по фак
ту ничего не работает. Firefox, естественно,
предложит загрузить подходящий модуль, но
мы-то с вами знаем, что из этого ничего
не выйдет; а пользователь зайдет в тупик.
Инсталлировать Flash-player от Adobe вручную
для новобранца весьма непросто, даже если
он знает, откуда его можно скачать. Политика
Adobe в отношении OEM настолько либераль-
на, что производители eSys могли бы преспо-
койно предустановить Flash. Пусть такое ПО
может «запятнать» систему щепоткой «несво-
боды», но лица, кому эти пятна не дают покоя,
обычно способны инсталлировать и стериль-
ную систему с сопроводительного диска.

Выходит, что это не проблемы Ubuntu. Да
это и не проблемы самого устройства: скорее,
упущенные возможности завоевать симпатии
пользователей, что могло бы благотворно
отразиться на имидже Linux.

Компьютер явно заслуживает внимания;
его легко использовать как домашний сер-
вер или настольную систему для непритяза-
тельного пользователя. Скорости процессора
вполне достаточно для повседневных нужд.
Правда, воспроизведение фильмов несколько
отрывистое, а 3D-эффекты Compiz недоступ-
ны, но ведь для рабочей лошадки это не глав-
ное. Зато устройство вызывающе дешево, и в
этом есть своя «изюминка». Мы рекомендуем
взять да и установить на купленный компью-
тер свой любимый дистрибутив – терять особо
нечего.

LXF97:Paragon NTFS

2008-03-09T12:28:45Z

OWeRQ: /* Производительность */

== Paragon NTFS for Linux 6.0 ==
''Нужна запись на жесткие диски Windows XP или Vista из-под Linux?
'''Нейл Ботвик''' тестирует единственное потенциальное решение
с поддержкой сжатия NTFS.''

Пользуясь открытым ПО, мы прини-
маем как должное даваемую им сво-
боду. Здесь нет тайн, и программы
легко срабатываются друг с другом: ведь их
внутренние механизмы показаны в исходном
коде. Если нужен доступ к файловой системе
Linux из Windows, достаточно лишь устано-
вить драйвер – вся информация, необходи-
мая для его написания, открыта и доступна.
Попробуете сделать наоборот – совсем другая
история. В ядро Linux встраивается ограни-
ченная поддержка файловой системы NTFS,
ограниченная в том смысле, что безопас-
ным считается только чтение с этой системы.
Альтернатива – модуль NTFS-3G FUSE, предо-
ставляющий доступ и на чтение, и на запись.
Paragon сработал еще одну, коммерческую
альтернативу, но по плечу ли ей заставить вас
раскошелиться (а заодно и поступиться прин-
ципами свободного ПО)?

Существует две версии NTFS for Linux:
персональная, о которой пойдет речь в
нашей статье, устанавливает лишь драйвер
файловой системы без дополнительных
инструментов. Профессиональная версия
оснащена инструментами для создания,
изменения размеров, архивирования и дру-
гих операций с NTFS-разделами из-под
Linux. Обе версии могут похвалиться Live
CD для доступа к NTFS-разделам, включая
возможность резервного копирования дан-
ных на CD или DVD.

Как же работает программа? Прилично, и
очень быстро. Файловая система устанавли-
вается в качестве модуля ядра, поэтому перед
инсталляцией необходимо иметь исходный
код ядра и среду для компиляции, чего по
умолчанию в большинстве дистрибутивов нет,
но все необходимые компоненты присутству-
ют в стандартном репозитории. Установив их,
инсталлировать программу нетрудно: доста-
точно распаковать zip-архив и запустить sh
install.sh (не верьте документам, советующим
использовать ./install.sh, поскольку бит ‘x’ на
нем не установлен). Инсталлятор формирует
и инсталлирует модуль файловой системы,
затем разыскивает NTFS-разделы и добавляет
их в /etc/fstab. Есть возможность автоматичес-
кого монтирования таких разделов при загруз-
ке. Графического инсталлятора нет, а базовые
инструкции, пожалуй, чересчур подробны, но
запуск инсталляционного скрипта – это все,
что вам нужно сделать.

Будучи установленной, файловая система
монтируется так же, как и любая другая, но,
вследствие различий с NTFS, получить такие
же права доступа и владения, как в Linux,
не получится. Вместо этого предоставляются
параметры монтирования с указанием вла-
дельца, группы и прав доступа по умолчанию
для файлов, совершенно так же, как с встро-
енными в ядро файловыми системами FAT.

==== Производительность (врезка) ====
Мы пробовали запустить тестовые программы bonnie, bonnie++ и
iozone, но они не работают с NTFS For Linux, и это показывает, что
некоторые важные функции файловой системы упущены. Но вряд ли
кто-нибудь заведет базу данных или почтовый сервер на NTFS-разде-
ле, да и сверхскоростное массовое копирование/создание файлов
вряд ли понадобится. Так что мы обошлись тестами попроще. Они
состояли из копирования двух наборов файлов в обоих направлениях.
Первый набор состоял из 4 ГБ больших видеофайлов, чтобы оценить
максимальную скорость копирования. Второй набор, из 713 МБ малых
файлов (49900 на два «ядерных» дерева), показывал способности
обращения со сложными файловыми структурами при сравнительно
малом объеме передаваемых данных. NTFS For Linux оказалась мед-
леннее NTFS-3G в первом случае, при копировании файлов большого
объема, и быстрее – во втором, при наличии сложной системы фай-
лов. Полученные цифры приводятся ниже.

{|
|
|NTFS for Linux
|NTFS-3G
|-
|Запись 4 ГБ больших файлов
|80 секунд
|128 секунд
|-
|Чтение 4 ГБ больших файлов
|207 секунд
|108 секунд
|-
|Запись 713 МБ малых файлов
|99 секунд
|806 секунд
|-
|Чтение 713 МБ малых файлов
|105 секунд
|545 секунд
|}

=== Давление сжатия? ===
83-страничное руководство, доступное на сай-
те Paragon (но не включенное в загружаемый
архив) покрывает вопросы инсталляции и раз-
личные параметры монтирования файловых
систем NTFS, причем речь идет в основном
об инструментах профессиональной версии.
Существенное отличие от NTFS-3G – обраще-
ние со сжатыми файлами. Это файлы, сжатые
на уровне файловой системы, а не обычные
zip-архивы. Хотя читать такие файлы могут
многие файловые системы, записывать в этот
формат умеет лишь NTFS for Linux – и если у
вас сжатая NTFS, ваш выбор уже сделан. LXF

LXF97:Paragon NTFS

2008-03-09T12:27:43Z

OWeRQ: Новая: == Paragon NTFS for Linux 6.0 == ''Нужна запись на жесткие диски Windows XP или Vista из-под Linux? '''Нейл Ботвик''' тестирует еди...

== Paragon NTFS for Linux 6.0 ==
''Нужна запись на жесткие диски Windows XP или Vista из-под Linux?
'''Нейл Ботвик''' тестирует единственное потенциальное решение
с поддержкой сжатия NTFS.''

Пользуясь открытым ПО, мы прини-
маем как должное даваемую им сво-
боду. Здесь нет тайн, и программы
легко срабатываются друг с другом: ведь их
внутренние механизмы показаны в исходном
коде. Если нужен доступ к файловой системе
Linux из Windows, достаточно лишь устано-
вить драйвер – вся информация, необходи-
мая для его написания, открыта и доступна.
Попробуете сделать наоборот – совсем другая
история. В ядро Linux встраивается ограни-
ченная поддержка файловой системы NTFS,
ограниченная в том смысле, что безопас-
ным считается только чтение с этой системы.
Альтернатива – модуль NTFS-3G FUSE, предо-
ставляющий доступ и на чтение, и на запись.
Paragon сработал еще одну, коммерческую
альтернативу, но по плечу ли ей заставить вас
раскошелиться (а заодно и поступиться прин-
ципами свободного ПО)?

Существует две версии NTFS for Linux:
персональная, о которой пойдет речь в
нашей статье, устанавливает лишь драйвер
файловой системы без дополнительных
инструментов. Профессиональная версия
оснащена инструментами для создания,
изменения размеров, архивирования и дру-
гих операций с NTFS-разделами из-под
Linux. Обе версии могут похвалиться Live
CD для доступа к NTFS-разделам, включая
возможность резервного копирования дан-
ных на CD или DVD.

Как же работает программа? Прилично, и
очень быстро. Файловая система устанавли-
вается в качестве модуля ядра, поэтому перед
инсталляцией необходимо иметь исходный
код ядра и среду для компиляции, чего по
умолчанию в большинстве дистрибутивов нет,
но все необходимые компоненты присутству-
ют в стандартном репозитории. Установив их,
инсталлировать программу нетрудно: доста-
точно распаковать zip-архив и запустить sh
install.sh (не верьте документам, советующим
использовать ./install.sh, поскольку бит ‘x’ на
нем не установлен). Инсталлятор формирует
и инсталлирует модуль файловой системы,
затем разыскивает NTFS-разделы и добавляет
их в /etc/fstab. Есть возможность автоматичес-
кого монтирования таких разделов при загруз-
ке. Графического инсталлятора нет, а базовые
инструкции, пожалуй, чересчур подробны, но
запуск инсталляционного скрипта – это все,
что вам нужно сделать.

Будучи установленной, файловая система
монтируется так же, как и любая другая, но,
вследствие различий с NTFS, получить такие
же права доступа и владения, как в Linux,
не получится. Вместо этого предоставляются
параметры монтирования с указанием вла-
дельца, группы и прав доступа по умолчанию
для файлов, совершенно так же, как с встро-
енными в ядро файловыми системами FAT.

==== Производительность ====
Мы пробовали запустить тестовые программы bonnie, bonnie++ и
iozone, но они не работают с NTFS For Linux, и это показывает, что
некоторые важные функции файловой системы упущены. Но вряд ли
кто-нибудь заведет базу данных или почтовый сервер на NTFS-разде-
ле, да и сверхскоростное массовое копирование/создание файлов
вряд ли понадобится. Так что мы обошлись тестами попроще. Они
состояли из копирования двух наборов файлов в обоих направлениях.
Первый набор состоял из 4 ГБ больших видеофайлов, чтобы оценить
максимальную скорость копирования. Второй набор, из 713 МБ малых
файлов (49900 на два «ядерных» дерева), показывал способности
обращения со сложными файловыми структурами при сравнительно
малом объеме передаваемых данных. NTFS For Linux оказалась мед-
леннее NTFS-3G в первом случае, при копировании файлов большого
объема, и быстрее – во втором, при наличии сложной системы фай-
лов. Полученные цифры приводятся ниже.

{|
|
|NTFS for Linux
|NTFS-3G
|-
|Запись 4 ГБ больших файлов
|80 секунд
|128 секунд
|-
|Чтение 4 ГБ больших файлов
|207 секунд
|108 секунд
|-
|Запись 713 МБ малых файлов
|99 секунд
|806 секунд
|-
|Чтение 713 МБ малых файлов
|105 секунд
|545 секунд
|}

=== Давление сжатия? ===
83-страничное руководство, доступное на сай-
те Paragon (но не включенное в загружаемый
архив) покрывает вопросы инсталляции и раз-
личные параметры монтирования файловых
систем NTFS, причем речь идет в основном
об инструментах профессиональной версии.
Существенное отличие от NTFS-3G – обраще-
ние со сжатыми файлами. Это файлы, сжатые
на уровне файловой системы, а не обычные
zip-архивы. Хотя читать такие файлы могут
многие файловые системы, записывать в этот
формат умеет лишь NTFS for Linux – и если у
вас сжатая NTFS, ваш выбор уже сделан. LXF

LXF97:Bash

2008-03-09T12:11:57Z

OWeRQ:

== Bash: Используем командную строку ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользователям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вошли в систему; очень удобно, когда вы работаете с несколькими учетными записями, используемыми для решения различных задач, и постоянно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напечатав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечатали. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может пригодиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегодня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

=== Часть 1: По Grep’у! ===
Вот теперь повеселимся! Grep – команда, которая находит слова в
файлах. Охотно сказала бы, что ее название произошло от слова
"поиск" по-клингонски, но это было бы неправдой и только укрепило бы стереотип, что все технари любят Star Trek! На самом деле
название команды – сокращение от "Глобальный Парсер Регулярных
Выражений" (Global Regular Expression Parser), что означает "глобальный поиск строк, соответствующих регулярному выражению, и их
вывод на экран". Название команды происходит от команды текстового
редактора ed g/re/p, выполняющей подобные действия.
Начнем с создания специального каталога, где будем размещать новые
файлы. Чтобы убедиться, что каталог создан, используйте команду ls.
<code>
probert@ubuntu:~$ mkdir Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Откроем текстовый редактор и создадим новый файл report1.txt:
<code>
probert@ubuntu:~$ pico report1.txt
</code>
Pico – это текстовый редактор, который я использовала при написании
этой статьи. В дистрибутив Linux включено несколько текстовых редакторов; выбор одного из них определяется лишь вашими предпочтениями и наличием у редактора специальных функций, которые помогут
в решении именно вашей задачи. Когда текстовый редактор откроется,
напечатайте слово CompanyABC. Затем точно так же создайте второй
файл с именем report2.txt, который будет содержать слово companyabc.
Закончив, введите команду ls, и вы увидите примерно такой список:
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music report1.txt report2.txt Work
</code>
Обратите внимание, что файлы, которые мы создали, находятся рядом
с каталогом Work. Давайте переместим их в нужный каталог:
<code>
probert@ubuntu:~$ mv report*.txt /home/probert/Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Звездочка (*) – это специальный символ, который позволяет нам
делать все, что мы хотим, с файлами, название которых начинается со
слова report; каждый из таких файлов включается в команду. У меня
есть правила именования файлов и разделения их на категории, которых я строго придерживаюсь. Например, названия всех файлов отчетов
начинаются со слова report, счетов – со слова invoice и т.д. Пускай это
выглядит как ритуальные действия безнадежно больного ОКР, зато при
наличии методичного подхода нужные вещи находятся очень быстро!
Переместимся в каталог Work и снова используем ls, чтобы убедиться,
что все файлы перемещены:
<code>
probert@ubuntu:~$ cd Work
probert@ubuntu:~/Work$ ls
report1.txt report2.txt
</code>
Сейчас мы сделаем следующий шаг в поисках этого крайне важного
файла для нашего коллеги. Команда grep обладает множеством опций
(их список выведет команда man grep). Опция -r позволяет выполнить
рекурсивный поиск файлов, начиная с названного каталога, а опция -i
выполнит поиск без учета регистра. Попробуйте следующие команды с
опцией -i и без -i и посмотрите, как это повлияет на результаты поиска.
<code>
probert@ubuntu:~/Work$ grep -r -i ‘CompanyABC’ /home/
probert/Work
</code>
Результат будет примерно таким:
<code>
/home/probert/Work/report1.txt:CompanyABC
/home/probert/Work/report2.txt:companyabc
</code>
Итак, мы нашли этот неуловимый файл; что же дальше?

=== Часть 2: Стандартный ввод-вывод ===
Стандартный ввод/вывод позволяет вводить данные в программу из
любого источника и выводить данные в любой источник. Таким образом, можно направить вывод одной команды непосредственно на ввод
другой команды... правда, мило? Linux предоставляет три канала ввода/вывода, более известных как потоки ввода/вывода. По умолчанию стандартный ввод подразумевает клавиатуру, стандартный вывод – экран.
Третий поток ввода/вывода – это на самом деле поток вывода для сообщений об ошибках, предупреждений и оповещений: так легче отличить
сообщения об ошибках от остальных сообщений. Поток ошибок обычно
также выводится на экран, но (как и каждый из трех стандартных потоков) может быть перенаправлен. Этим мы сейчас и займемся.
Есть два основных способа перенаправления потоков данных; мы
можем использовать > или | (перенаправление и каналы соответственно). Если нужно просто направить стандартный вывод в файл, можно
напечатать команда > файл. Давайте попробуем это на реальном примере: найдем все файлы с именем passwd в каталоге /etc. Наберите
<code>
find /etc -name passwd
</code>
Результат будет примерно таким (он зависит от особенностей вашего
дистрибутива Linux):
<code>
probert@ubuntu:~$ find /etc -name passwd
find: /etc/ssl/private: Permission denied
/etc/passwd
/etc/pam.d/passwd
find: /etc/cups/ssl: Permission denied
</code>
Обратите внимание, что команда генерирует как стандартный поток
вывода, так и поток ошибок. Сейчас мы создадим файл findresult и
перенаправим стандартный поток вывода в этот файл, оставив на экране только ошибки.
<code>
probert@ubuntu:~$ find /etc -name passwd > findresult
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Перенаправим эти ошибки в другой файл, finderrors, используя 2>.
<code>
probert@ubuntu:~$ find /etc -name passwd 2> finderrors
/etc/passwd
/etc/pam.d/passwd
</code>
Наберите ls, и вы получите результат, похожий на мой.
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples finderrors findresult LAN Music
</code>

Чтобы прочитать содержимое этих файлов, можно открыть их в текстовом редакторе pico:
<code>
probert@ubuntu:~$ pico findresult
</code>
Я предпочитаю просматривать небольшие файлы с помощью команды
cat. Ниже я использовала эту команду для просмотра результатов поиска в файлах findresult и finderrors.
<code>
probert@ubuntu:~$ cat findresult
/etc/passwd
/etc/pam.d/passwd
probert@ubuntu:~$ cat finderrors
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Вы также можете добавить информацию в файл с помощью команды
>>. Давайте перенаправим стандартный вывод, чтобы добавить информацию в наш первый файл findresult следующим образом:
<code>
probert@ubuntu:~$ find /etc -name passwd 2>> findresult
</code>
Вы можете снова проверить результаты с помощью команды cat
findresult. Второй способ перенаправления потоков – вывод одной
команды прямо на вход другой (канализация). Давайте проверим
содержимое каталога /usr/lib, где находятся объектные файлы, библиотеки и системные двоичные файлы. В моем каталоге /usr/lib примерно полторы тысячи файлов – многовато, чтобы прокручивать этот
список один за другим! Если мы перенаправим вывод ls на ввод команды less, то получим список, в котором можно перемещаться по страницам, в удобном для нас темпе. Попробуйте:
<code>
ls /usr/lib | less
</code>
Достигнув конца документа, нажмите клавишу Q, чтобы вернуться в
командную строку. Вы также можете предварительно отсортировать
этот список по убыванию, например, таким образом:
<code>
ls /usr/lib | sort -r | less
</code>
Краеугольный камень философии Unix заключается в том, чтобы каждая программа делала что-то одно по-настоящему хорошо, позволяя
использовать свой вывод как ввод другой программы. Использование
каналов позволяет провести этот принцип в жизнь, создавая очень
эффективные цепочки команд.
Теперь, разузнав, как работают grep и каналы, сведем их вместе для
поиска того самого отчета и отправим его нашему коллеге:
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat report1.txt | mail colleague@work.com
</code>
Миссия завершена!

==== Помощь по grep (врезка) ====
Поскольку grep производит поиск соответствий по шаблонам, вы
должны предоставить ему регулярное выражение для этого шаблона.
Регулярные выражения бывают простыми и сложными. Наиболее распространенные (и простые) типы регулярных выражений выглядят так:
*abc Соответствует строкам, которые содержат "abc" в любом месте.
*^abc Соответствует строкам, начинающимся с "abc".

==== Мини-проект: команды для умных (врезка) ====
Есть несколько общих команд, о которых
полезно знать. Привожу некоторые из них без
объяснений; эти команды можно использовать
независимо от дополнительных опций.
Наберите их и посмотрите на результат.

{|
|date
|df
|-
|date +%D
|free
|-
|date +%T
|du
|-
|cal
|top
|-
|cal 1066
|ps
|}

----
Через месяц Moнтирование, создание резервных копий, распаковка файлов из tar и zip.

LXF97:Bash

2008-03-08T17:46:38Z

OWeRQ:

== Bash: Используем командную строку ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользователям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вошли в систему; очень удобно, когда вы работаете с несколькими учетными записями, используемыми для решения различных задач, и постоянно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напечатав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечатали. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может пригодиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегодня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

=== Часть 1: По Grep’у! ===
Вот теперь повеселимся! Grep – команда, которая находит слова в
файлах. Охотно сказала бы, что ее название произошло от слова
"поиск" по-клингонски, но это было бы неправдой и только укрепило бы стереотип, что все технари любят Star Trek! На самом деле
название команды – сокращение от "Глобальный Парсер Регулярных
Выражений" (Global Regular Expression Parser), что означает "глобальный поиск строк, соответствующих регулярному выражению, и их
вывод на экран". Название команды происходит от команды текстового
редактора ed g/re/p, выполняющей подобные действия.
Начнем с создания специального каталога, где будем размещать новые
файлы. Чтобы убедиться, что каталог создан, используйте команду ls.
<code>
probert@ubuntu:~$ mkdir Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Откроем текстовый редактор и создадим новый файл report1.txt:
<code>
probert@ubuntu:~$ pico report1.txt
</code>
Pico – это текстовый редактор, который я использовала при написании
этой статьи. В дистрибутив Linux включено несколько текстовых редакторов; выбор одного из них определяется лишь вашими предпочтениями и наличием у редактора специальных функций, которые помогут
в решении именно вашей задачи. Когда текстовый редактор откроется,
напечатайте слово CompanyABC. Затем точно так же создайте второй
файл с именем report2.txt, который будет содержать слово companyabc.
Закончив, введите команду ls, и вы увидите примерно такой список:
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music report1.txt report2.txt Work
</code>
Обратите внимание, что файлы, которые мы создали, находятся рядом
с каталогом Work. Давайте переместим их в нужный каталог:
<code>
probert@ubuntu:~$ mv report*.txt /home/probert/Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Звездочка (*) – это специальный символ, который позволяет нам
делать все, что мы хотим, с файлами, название которых начинается со
слова report; каждый из таких файлов включается в команду. У меня
есть правила именования файлов и разделения их на категории, которых я строго придерживаюсь. Например, названия всех файлов отчетов
начинаются со слова report, счетов – со слова invoice и т.д. Пускай это
выглядит как ритуальные действия безнадежно больного ОКР, зато при
наличии методичного подхода нужные вещи находятся очень быстро!
Переместимся в каталог Work и снова используем ls, чтобы убедиться,
что все файлы перемещены:
<code>
probert@ubuntu:~$ cd Work
probert@ubuntu:~/Work$ ls
report1.txt report2.txt
</code>
Сейчас мы сделаем следующий шаг в поисках этого крайне важного
файла для нашего коллеги. Команда grep обладает множеством опций
(их список выведет команда man grep). Опция -r позволяет выполнить
рекурсивный поиск файлов, начиная с названного каталога, а опция -i
выполнит поиск без учета регистра. Попробуйте следующие команды с
опцией -i и без -i и посмотрите, как это повлияет на результаты поиска.
<code>
probert@ubuntu:~/Work$ grep -r -i ‘CompanyABC’ /home/
probert/Work
</code>
Результат будет примерно таким:
<code>
/home/probert/Work/report1.txt:CompanyABC
/home/probert/Work/report2.txt:companyabc
</code>
Итак, мы нашли этот неуловимый файл; что же дальше?

=== Часть 2: Стандартный ввод-вывод ===
Стандартный ввод/вывод позволяет вводить данные в программу из
любого источника и выводить данные в любой источник. Таким образом, можно направить вывод одной команды непосредственно на ввод
другой команды... правда, мило? Linux предоставляет три канала ввода/вывода, более известных как потоки ввода/вывода. По умолчанию стандартный ввод подразумевает клавиатуру, стандартный вывод – экран.
Третий поток ввода/вывода – это на самом деле поток вывода для сообщений об ошибках, предупреждений и оповещений: так легче отличить
сообщения об ошибках от остальных сообщений. Поток ошибок обычно
также выводится на экран, но (как и каждый из трех стандартных потоков) может быть перенаправлен. Этим мы сейчас и займемся.
Есть два основных способа перенаправления потоков данных; мы
можем использовать > или | (перенаправление и каналы соответственно). Если нужно просто направить стандартный вывод в файл, можно
напечатать команда > файл. Давайте попробуем это на реальном примере: найдем все файлы с именем passwd в каталоге /etc. Наберите
<code>
find /etc -name passwd
</code>
Результат будет примерно таким (он зависит от особенностей вашего
дистрибутива Linux):
<code>
probert@ubuntu:~$ find /etc -name passwd
find: /etc/ssl/private: Permission denied
/etc/passwd
/etc/pam.d/passwd
find: /etc/cups/ssl: Permission denied
</code>
Обратите внимание, что команда генерирует как стандартный поток
вывода, так и поток ошибок. Сейчас мы создадим файл findresult и
перенаправим стандартный поток вывода в этот файл, оставив на экране только ошибки.
<code>
probert@ubuntu:~$ find /etc -name passwd > findresult
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Перенаправим эти ошибки в другой файл, finderrors, используя 2>.
<code>
probert@ubuntu:~$ find /etc -name passwd 2> finderrors
/etc/passwd
/etc/pam.d/passwd
</code>
Наберите ls, и вы получите результат, похожий на мой.
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples finderrors findresult LAN Music
</code>

Чтобы прочитать содержимое этих файлов, можно открыть их в текстовом редакторе pico:
<code>
probert@ubuntu:~$ pico findresult
</code>
Я предпочитаю просматривать небольшие файлы с помощью команды
cat. Ниже я использовала эту команду для просмотра результатов поиска в файлах findresult и finderrors.
<code>
probert@ubuntu:~$ cat findresult
/etc/passwd
/etc/pam.d/passwd
probert@ubuntu:~$ cat finderrors
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Вы также можете добавить информацию в файл с помощью команды
>>. Давайте перенаправим стандартный вывод, чтобы добавить информацию в наш первый файл findresult следующим образом:
<code>
probert@ubuntu:~$ find /etc -name passwd 2>> findresult
</code>
Вы можете снова проверить результаты с помощью команды cat
findresult. Второй способ перенаправления потоков – вывод одной
команды прямо на вход другой (канализация). Давайте проверим
содержимое каталога /usr/lib, где находятся объектные файлы, библиотеки и системные двоичные файлы. В моем каталоге /usr/lib примерно полторы тысячи файлов – многовато, чтобы прокручивать этот
список один за другим! Если мы перенаправим вывод ls на ввод команды less, то получим список, в котором можно перемещаться по страницам, в удобном для нас темпе. Попробуйте:
<code>
ls /usr/lib | less
</code>
Достигнув конца документа, нажмите клавишу Q, чтобы вернуться в
командную строку. Вы также можете предварительно отсортировать
этот список по убыванию, например, таким образом:
<code>
ls /usr/lib | sort -r | less
</code>
Краеугольный камень философии Unix заключается в том, чтобы каждая программа делала что-то одно по-настоящему хорошо, позволяя
использовать свой вывод как ввод другой программы. Использование
каналов позволяет провести этот принцип в жизнь, создавая очень
эффективные цепочки команд.
Теперь, разузнав, как работают grep и каналы, сведем их вместе для
поиска того самого отчета и отправим его нашему коллеге:
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat report1.txt | mail colleague@work.com
</code>
Миссия завершена!

==== Помощь по grep (вырезка) ====
Поскольку grep производит поиск соответствий по шаблонам, вы
должны предоставить ему регулярное выражение для этого шаблона.
Регулярные выражения бывают простыми и сложными. Наиболее распространенные (и простые) типы регулярных выражений выглядят так:
*abc Соответствует строкам, которые содержат "abc" в любом месте.
*^abc Соответствует строкам, начинающимся с "abc".

==== Мини-проект: команды для умных (вырезка) ====
Есть несколько общих команд, о которых
полезно знать. Привожу некоторые из них без
объяснений; эти команды можно использовать
независимо от дополнительных опций.
Наберите их и посмотрите на результат.

{|
|date
|df
|-
|date +%D
|free
|-
|date +%T
|du
|-
|cal
|top
|-
|cal 1066
|ps
|}

----
Через месяц Moнтирование, создание резервных копий, распаковка файлов из tar и zip.

LXF97:Bash

2008-03-08T17:44:55Z

OWeRQ: /* Мини-проект: команды для умных */

== Bash: Используем командную строку ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользователям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вошли в систему; очень удобно, когда вы работаете с несколькими учетными записями, используемыми для решения различных задач, и постоянно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напечатав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечатали. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может пригодиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегодня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

=== Часть 1: По Grep’у! ===
Вот теперь повеселимся! Grep – команда, которая находит слова в
файлах. Охотно сказала бы, что ее название произошло от слова
"поиск" по-клингонски, но это было бы неправдой и только укрепило бы стереотип, что все технари любят Star Trek! На самом деле
название команды – сокращение от "Глобальный Парсер Регулярных
Выражений" (Global Regular Expression Parser), что означает "глобальный поиск строк, соответствующих регулярному выражению, и их
вывод на экран". Название команды происходит от команды текстового
редактора ed g/re/p, выполняющей подобные действия.
Начнем с создания специального каталога, где будем размещать новые
файлы. Чтобы убедиться, что каталог создан, используйте команду ls.
<code>
probert@ubuntu:~$ mkdir Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Откроем текстовый редактор и создадим новый файл report1.txt:
<code>
probert@ubuntu:~$ pico report1.txt
</code>
Pico – это текстовый редактор, который я использовала при написании
этой статьи. В дистрибутив Linux включено несколько текстовых редакторов; выбор одного из них определяется лишь вашими предпочтениями и наличием у редактора специальных функций, которые помогут
в решении именно вашей задачи. Когда текстовый редактор откроется,
напечатайте слово CompanyABC. Затем точно так же создайте второй
файл с именем report2.txt, который будет содержать слово companyabc.
Закончив, введите команду ls, и вы увидите примерно такой список:
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music report1.txt report2.txt Work
</code>
Обратите внимание, что файлы, которые мы создали, находятся рядом
с каталогом Work. Давайте переместим их в нужный каталог:
<code>
probert@ubuntu:~$ mv report*.txt /home/probert/Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Звездочка (*) – это специальный символ, который позволяет нам
делать все, что мы хотим, с файлами, название которых начинается со
слова report; каждый из таких файлов включается в команду. У меня
есть правила именования файлов и разделения их на категории, которых я строго придерживаюсь. Например, названия всех файлов отчетов
начинаются со слова report, счетов – со слова invoice и т.д. Пускай это
выглядит как ритуальные действия безнадежно больного ОКР, зато при
наличии методичного подхода нужные вещи находятся очень быстро!
Переместимся в каталог Work и снова используем ls, чтобы убедиться,
что все файлы перемещены:
<code>
probert@ubuntu:~$ cd Work
probert@ubuntu:~/Work$ ls
report1.txt report2.txt
</code>
Сейчас мы сделаем следующий шаг в поисках этого крайне важного
файла для нашего коллеги. Команда grep обладает множеством опций
(их список выведет команда man grep). Опция -r позволяет выполнить
рекурсивный поиск файлов, начиная с названного каталога, а опция -i
выполнит поиск без учета регистра. Попробуйте следующие команды с
опцией -i и без -i и посмотрите, как это повлияет на результаты поиска.
<code>
probert@ubuntu:~/Work$ grep -r -i ‘CompanyABC’ /home/
probert/Work
</code>
Результат будет примерно таким:
<code>
/home/probert/Work/report1.txt:CompanyABC
/home/probert/Work/report2.txt:companyabc
</code>
Итак, мы нашли этот неуловимый файл; что же дальше?

=== Часть 2: Стандартный ввод-вывод ===
Стандартный ввод/вывод позволяет вводить данные в программу из
любого источника и выводить данные в любой источник. Таким образом, можно направить вывод одной команды непосредственно на ввод
другой команды... правда, мило? Linux предоставляет три канала ввода/вывода, более известных как потоки ввода/вывода. По умолчанию стандартный ввод подразумевает клавиатуру, стандартный вывод – экран.
Третий поток ввода/вывода – это на самом деле поток вывода для сообщений об ошибках, предупреждений и оповещений: так легче отличить
сообщения об ошибках от остальных сообщений. Поток ошибок обычно
также выводится на экран, но (как и каждый из трех стандартных потоков) может быть перенаправлен. Этим мы сейчас и займемся.
Есть два основных способа перенаправления потоков данных; мы
можем использовать > или | (перенаправление и каналы соответственно). Если нужно просто направить стандартный вывод в файл, можно
напечатать команда > файл. Давайте попробуем это на реальном примере: найдем все файлы с именем passwd в каталоге /etc. Наберите
<code>
find /etc -name passwd
</code>
Результат будет примерно таким (он зависит от особенностей вашего
дистрибутива Linux):
<code>
probert@ubuntu:~$ find /etc -name passwd
find: /etc/ssl/private: Permission denied
/etc/passwd
/etc/pam.d/passwd
find: /etc/cups/ssl: Permission denied
</code>
Обратите внимание, что команда генерирует как стандартный поток
вывода, так и поток ошибок. Сейчас мы создадим файл findresult и
перенаправим стандартный поток вывода в этот файл, оставив на экране только ошибки.
<code>
probert@ubuntu:~$ find /etc -name passwd > findresult
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Перенаправим эти ошибки в другой файл, finderrors, используя 2>.
<code>
probert@ubuntu:~$ find /etc -name passwd 2> finderrors
/etc/passwd
/etc/pam.d/passwd
</code>
Наберите ls, и вы получите результат, похожий на мой.
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples finderrors findresult LAN Music
</code>

==== Помощь по grep (вырезка) ====
Поскольку grep производит поиск соответствий по шаблонам, вы
должны предоставить ему регулярное выражение для этого шаблона.
Регулярные выражения бывают простыми и сложными. Наиболее распространенные (и простые) типы регулярных выражений выглядят так:
*abc Соответствует строкам, которые содержат "abc" в любом месте.
*^abc Соответствует строкам, начинающимся с "abc".

Чтобы прочитать содержимое этих файлов, можно открыть их в текстовом редакторе pico:
<code>
probert@ubuntu:~$ pico findresult
</code>
Я предпочитаю просматривать небольшие файлы с помощью команды
cat. Ниже я использовала эту команду для просмотра результатов поиска в файлах findresult и finderrors.
<code>
probert@ubuntu:~$ cat findresult
/etc/passwd
/etc/pam.d/passwd
probert@ubuntu:~$ cat finderrors
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Вы также можете добавить информацию в файл с помощью команды
>>. Давайте перенаправим стандартный вывод, чтобы добавить информацию в наш первый файл findresult следующим образом:
<code>
probert@ubuntu:~$ find /etc -name passwd 2>> findresult
</code>
Вы можете снова проверить результаты с помощью команды cat
findresult. Второй способ перенаправления потоков – вывод одной
команды прямо на вход другой (канализация). Давайте проверим
содержимое каталога /usr/lib, где находятся объектные файлы, библиотеки и системные двоичные файлы. В моем каталоге /usr/lib примерно полторы тысячи файлов – многовато, чтобы прокручивать этот
список один за другим! Если мы перенаправим вывод ls на ввод команды less, то получим список, в котором можно перемещаться по страницам, в удобном для нас темпе. Попробуйте:
<code>
ls /usr/lib | less
</code>
Достигнув конца документа, нажмите клавишу Q, чтобы вернуться в
командную строку. Вы также можете предварительно отсортировать
этот список по убыванию, например, таким образом:
<code>
ls /usr/lib | sort -r | less
</code>
Краеугольный камень философии Unix заключается в том, чтобы каждая программа делала что-то одно по-настоящему хорошо, позволяя
использовать свой вывод как ввод другой программы. Использование
каналов позволяет провести этот принцип в жизнь, создавая очень
эффективные цепочки команд.
Теперь, разузнав, как работают grep и каналы, сведем их вместе для
поиска того самого отчета и отправим его нашему коллеге:
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat report1.txt | mail colleague@work.com
</code>
Миссия завершена!

==== Мини-проект: команды для умных (вырезка) ====
Есть несколько общих команд, о которых
полезно знать. Привожу некоторые из них без
объяснений; эти команды можно использовать
независимо от дополнительных опций.
Наберите их и посмотрите на результат.

{|
|date
|df
|-
|date +%D
|free
|-
|date +%T
|du
|-
|cal
|top
|-
|cal 1066
|ps
|}

Через месяц Moнтирование, создание резервных копий, распаковка файлов из tar и zip.

LXF97:Bash

2008-03-08T17:40:18Z

OWeRQ: /* Помощь по grep (вырезка) */

== Bash: Используем командную строку ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользователям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вошли в систему; очень удобно, когда вы работаете с несколькими учетными записями, используемыми для решения различных задач, и постоянно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напечатав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечатали. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может пригодиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегодня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

=== Часть 1: По Grep’у! ===
Вот теперь повеселимся! Grep – команда, которая находит слова в
файлах. Охотно сказала бы, что ее название произошло от слова
"поиск" по-клингонски, но это было бы неправдой и только укрепило бы стереотип, что все технари любят Star Trek! На самом деле
название команды – сокращение от "Глобальный Парсер Регулярных
Выражений" (Global Regular Expression Parser), что означает "глобальный поиск строк, соответствующих регулярному выражению, и их
вывод на экран". Название команды происходит от команды текстового
редактора ed g/re/p, выполняющей подобные действия.
Начнем с создания специального каталога, где будем размещать новые
файлы. Чтобы убедиться, что каталог создан, используйте команду ls.
<code>
probert@ubuntu:~$ mkdir Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Откроем текстовый редактор и создадим новый файл report1.txt:
<code>
probert@ubuntu:~$ pico report1.txt
</code>
Pico – это текстовый редактор, который я использовала при написании
этой статьи. В дистрибутив Linux включено несколько текстовых редакторов; выбор одного из них определяется лишь вашими предпочтениями и наличием у редактора специальных функций, которые помогут
в решении именно вашей задачи. Когда текстовый редактор откроется,
напечатайте слово CompanyABC. Затем точно так же создайте второй
файл с именем report2.txt, который будет содержать слово companyabc.
Закончив, введите команду ls, и вы увидите примерно такой список:
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music report1.txt report2.txt Work
</code>
Обратите внимание, что файлы, которые мы создали, находятся рядом
с каталогом Work. Давайте переместим их в нужный каталог:
<code>
probert@ubuntu:~$ mv report*.txt /home/probert/Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Звездочка (*) – это специальный символ, который позволяет нам
делать все, что мы хотим, с файлами, название которых начинается со
слова report; каждый из таких файлов включается в команду. У меня
есть правила именования файлов и разделения их на категории, которых я строго придерживаюсь. Например, названия всех файлов отчетов
начинаются со слова report, счетов – со слова invoice и т.д. Пускай это
выглядит как ритуальные действия безнадежно больного ОКР, зато при
наличии методичного подхода нужные вещи находятся очень быстро!
Переместимся в каталог Work и снова используем ls, чтобы убедиться,
что все файлы перемещены:
<code>
probert@ubuntu:~$ cd Work
probert@ubuntu:~/Work$ ls
report1.txt report2.txt
</code>
Сейчас мы сделаем следующий шаг в поисках этого крайне важного
файла для нашего коллеги. Команда grep обладает множеством опций
(их список выведет команда man grep). Опция -r позволяет выполнить
рекурсивный поиск файлов, начиная с названного каталога, а опция -i
выполнит поиск без учета регистра. Попробуйте следующие команды с
опцией -i и без -i и посмотрите, как это повлияет на результаты поиска.
<code>
probert@ubuntu:~/Work$ grep -r -i ‘CompanyABC’ /home/
probert/Work
</code>
Результат будет примерно таким:
<code>
/home/probert/Work/report1.txt:CompanyABC
/home/probert/Work/report2.txt:companyabc
</code>
Итак, мы нашли этот неуловимый файл; что же дальше?

=== Часть 2: Стандартный ввод-вывод ===
Стандартный ввод/вывод позволяет вводить данные в программу из
любого источника и выводить данные в любой источник. Таким образом, можно направить вывод одной команды непосредственно на ввод
другой команды... правда, мило? Linux предоставляет три канала ввода/вывода, более известных как потоки ввода/вывода. По умолчанию стандартный ввод подразумевает клавиатуру, стандартный вывод – экран.
Третий поток ввода/вывода – это на самом деле поток вывода для сообщений об ошибках, предупреждений и оповещений: так легче отличить
сообщения об ошибках от остальных сообщений. Поток ошибок обычно
также выводится на экран, но (как и каждый из трех стандартных потоков) может быть перенаправлен. Этим мы сейчас и займемся.
Есть два основных способа перенаправления потоков данных; мы
можем использовать > или | (перенаправление и каналы соответственно). Если нужно просто направить стандартный вывод в файл, можно
напечатать команда > файл. Давайте попробуем это на реальном примере: найдем все файлы с именем passwd в каталоге /etc. Наберите
<code>
find /etc -name passwd
</code>
Результат будет примерно таким (он зависит от особенностей вашего
дистрибутива Linux):
<code>
probert@ubuntu:~$ find /etc -name passwd
find: /etc/ssl/private: Permission denied
/etc/passwd
/etc/pam.d/passwd
find: /etc/cups/ssl: Permission denied
</code>
Обратите внимание, что команда генерирует как стандартный поток
вывода, так и поток ошибок. Сейчас мы создадим файл findresult и
перенаправим стандартный поток вывода в этот файл, оставив на экране только ошибки.
<code>
probert@ubuntu:~$ find /etc -name passwd > findresult
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Перенаправим эти ошибки в другой файл, finderrors, используя 2>.
<code>
probert@ubuntu:~$ find /etc -name passwd 2> finderrors
/etc/passwd
/etc/pam.d/passwd
</code>
Наберите ls, и вы получите результат, похожий на мой.
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples finderrors findresult LAN Music
</code>

==== Помощь по grep (вырезка) ====
Поскольку grep производит поиск соответствий по шаблонам, вы
должны предоставить ему регулярное выражение для этого шаблона.
Регулярные выражения бывают простыми и сложными. Наиболее распространенные (и простые) типы регулярных выражений выглядят так:
*abc Соответствует строкам, которые содержат "abc" в любом месте.
*^abc Соответствует строкам, начинающимся с "abc".

Чтобы прочитать содержимое этих файлов, можно открыть их в текстовом редакторе pico:
<code>
probert@ubuntu:~$ pico findresult
</code>
Я предпочитаю просматривать небольшие файлы с помощью команды
cat. Ниже я использовала эту команду для просмотра результатов поиска в файлах findresult и finderrors.
<code>
probert@ubuntu:~$ cat findresult
/etc/passwd
/etc/pam.d/passwd
probert@ubuntu:~$ cat finderrors
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Вы также можете добавить информацию в файл с помощью команды
>>. Давайте перенаправим стандартный вывод, чтобы добавить информацию в наш первый файл findresult следующим образом:
<code>
probert@ubuntu:~$ find /etc -name passwd 2>> findresult
</code>
Вы можете снова проверить результаты с помощью команды cat
findresult. Второй способ перенаправления потоков – вывод одной
команды прямо на вход другой (канализация). Давайте проверим
содержимое каталога /usr/lib, где находятся объектные файлы, библиотеки и системные двоичные файлы. В моем каталоге /usr/lib примерно полторы тысячи файлов – многовато, чтобы прокручивать этот
список один за другим! Если мы перенаправим вывод ls на ввод команды less, то получим список, в котором можно перемещаться по страницам, в удобном для нас темпе. Попробуйте:
<code>
ls /usr/lib | less
</code>
Достигнув конца документа, нажмите клавишу Q, чтобы вернуться в
командную строку. Вы также можете предварительно отсортировать
этот список по убыванию, например, таким образом:
<code>
ls /usr/lib | sort -r | less
</code>
Краеугольный камень философии Unix заключается в том, чтобы каждая программа делала что-то одно по-настоящему хорошо, позволяя
использовать свой вывод как ввод другой программы. Использование
каналов позволяет провести этот принцип в жизнь, создавая очень
эффективные цепочки команд.
Теперь, разузнав, как работают grep и каналы, сведем их вместе для
поиска того самого отчета и отправим его нашему коллеге:
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat report1.txt | mail colleague@work.com
</code>
Миссия завершена!

==== Мини-проект: команды для умных ====
Есть несколько общих команд, о которых
полезно знать. Привожу некоторые из них без
объяснений; эти команды можно использовать
независимо от дополнительных опций.
Наберите их и посмотрите на результат.
date df
date +%D free
date +%T du
cal top
cal 1066 ps

Через месяц Moнтирование, создание резервных копий, распаковка файлов из tar и zip.

LXF97:Bash

2008-03-08T17:39:36Z

OWeRQ: /* Часть 1: По Grep’у! */

== Bash: Используем командную строку ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользователям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вошли в систему; очень удобно, когда вы работаете с несколькими учетными записями, используемыми для решения различных задач, и постоянно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напечатав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечатали. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может пригодиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегодня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

=== Часть 1: По Grep’у! ===
Вот теперь повеселимся! Grep – команда, которая находит слова в
файлах. Охотно сказала бы, что ее название произошло от слова
"поиск" по-клингонски, но это было бы неправдой и только укрепило бы стереотип, что все технари любят Star Trek! На самом деле
название команды – сокращение от "Глобальный Парсер Регулярных
Выражений" (Global Regular Expression Parser), что означает "глобальный поиск строк, соответствующих регулярному выражению, и их
вывод на экран". Название команды происходит от команды текстового
редактора ed g/re/p, выполняющей подобные действия.
Начнем с создания специального каталога, где будем размещать новые
файлы. Чтобы убедиться, что каталог создан, используйте команду ls.
<code>
probert@ubuntu:~$ mkdir Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Откроем текстовый редактор и создадим новый файл report1.txt:
<code>
probert@ubuntu:~$ pico report1.txt
</code>
Pico – это текстовый редактор, который я использовала при написании
этой статьи. В дистрибутив Linux включено несколько текстовых редакторов; выбор одного из них определяется лишь вашими предпочтениями и наличием у редактора специальных функций, которые помогут
в решении именно вашей задачи. Когда текстовый редактор откроется,
напечатайте слово CompanyABC. Затем точно так же создайте второй
файл с именем report2.txt, который будет содержать слово companyabc.
Закончив, введите команду ls, и вы увидите примерно такой список:
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music report1.txt report2.txt Work
</code>
Обратите внимание, что файлы, которые мы создали, находятся рядом
с каталогом Work. Давайте переместим их в нужный каталог:
<code>
probert@ubuntu:~$ mv report*.txt /home/probert/Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Звездочка (*) – это специальный символ, который позволяет нам
делать все, что мы хотим, с файлами, название которых начинается со
слова report; каждый из таких файлов включается в команду. У меня
есть правила именования файлов и разделения их на категории, которых я строго придерживаюсь. Например, названия всех файлов отчетов
начинаются со слова report, счетов – со слова invoice и т.д. Пускай это
выглядит как ритуальные действия безнадежно больного ОКР, зато при
наличии методичного подхода нужные вещи находятся очень быстро!
Переместимся в каталог Work и снова используем ls, чтобы убедиться,
что все файлы перемещены:
<code>
probert@ubuntu:~$ cd Work
probert@ubuntu:~/Work$ ls
report1.txt report2.txt
</code>
Сейчас мы сделаем следующий шаг в поисках этого крайне важного
файла для нашего коллеги. Команда grep обладает множеством опций
(их список выведет команда man grep). Опция -r позволяет выполнить
рекурсивный поиск файлов, начиная с названного каталога, а опция -i
выполнит поиск без учета регистра. Попробуйте следующие команды с
опцией -i и без -i и посмотрите, как это повлияет на результаты поиска.
<code>
probert@ubuntu:~/Work$ grep -r -i ‘CompanyABC’ /home/
probert/Work
</code>
Результат будет примерно таким:
<code>
/home/probert/Work/report1.txt:CompanyABC
/home/probert/Work/report2.txt:companyabc
</code>
Итак, мы нашли этот неуловимый файл; что же дальше?

=== Часть 2: Стандартный ввод-вывод ===
Стандартный ввод/вывод позволяет вводить данные в программу из
любого источника и выводить данные в любой источник. Таким образом, можно направить вывод одной команды непосредственно на ввод
другой команды... правда, мило? Linux предоставляет три канала ввода/вывода, более известных как потоки ввода/вывода. По умолчанию стандартный ввод подразумевает клавиатуру, стандартный вывод – экран.
Третий поток ввода/вывода – это на самом деле поток вывода для сообщений об ошибках, предупреждений и оповещений: так легче отличить
сообщения об ошибках от остальных сообщений. Поток ошибок обычно
также выводится на экран, но (как и каждый из трех стандартных потоков) может быть перенаправлен. Этим мы сейчас и займемся.
Есть два основных способа перенаправления потоков данных; мы
можем использовать > или | (перенаправление и каналы соответственно). Если нужно просто направить стандартный вывод в файл, можно
напечатать команда > файл. Давайте попробуем это на реальном примере: найдем все файлы с именем passwd в каталоге /etc. Наберите
<code>
find /etc -name passwd
</code>
Результат будет примерно таким (он зависит от особенностей вашего
дистрибутива Linux):
<code>
probert@ubuntu:~$ find /etc -name passwd
find: /etc/ssl/private: Permission denied
/etc/passwd
/etc/pam.d/passwd
find: /etc/cups/ssl: Permission denied
</code>
Обратите внимание, что команда генерирует как стандартный поток
вывода, так и поток ошибок. Сейчас мы создадим файл findresult и
перенаправим стандартный поток вывода в этот файл, оставив на экране только ошибки.
<code>
probert@ubuntu:~$ find /etc -name passwd > findresult
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Перенаправим эти ошибки в другой файл, finderrors, используя 2>.
<code>
probert@ubuntu:~$ find /etc -name passwd 2> finderrors
/etc/passwd
/etc/pam.d/passwd
</code>
Наберите ls, и вы получите результат, похожий на мой.
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples finderrors findresult LAN Music
</code>

==== Помощь по grep (вырезка) ====
Поскольку grep производит поиск соответствий по шаблонам, вы
должны предоставить ему регулярное выражение для этого шаблона.
Регулярные выражения бывают простыми и сложными. Наиболее распространенные (и простые) типы регулярных выражений выглядят так:
*abc Соответствует строкам, которые содержат “abc” в любом месте.
*^abc Соответствует строкам, начинающимся с “abc”.

Чтобы прочитать содержимое этих файлов, можно открыть их в текстовом редакторе pico:
<code>
probert@ubuntu:~$ pico findresult
</code>
Я предпочитаю просматривать небольшие файлы с помощью команды
cat. Ниже я использовала эту команду для просмотра результатов поиска в файлах findresult и finderrors.
<code>
probert@ubuntu:~$ cat findresult
/etc/passwd
/etc/pam.d/passwd
probert@ubuntu:~$ cat finderrors
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Вы также можете добавить информацию в файл с помощью команды
>>. Давайте перенаправим стандартный вывод, чтобы добавить информацию в наш первый файл findresult следующим образом:
<code>
probert@ubuntu:~$ find /etc -name passwd 2>> findresult
</code>
Вы можете снова проверить результаты с помощью команды cat
findresult. Второй способ перенаправления потоков – вывод одной
команды прямо на вход другой (канализация). Давайте проверим
содержимое каталога /usr/lib, где находятся объектные файлы, библиотеки и системные двоичные файлы. В моем каталоге /usr/lib примерно полторы тысячи файлов – многовато, чтобы прокручивать этот
список один за другим! Если мы перенаправим вывод ls на ввод команды less, то получим список, в котором можно перемещаться по страницам, в удобном для нас темпе. Попробуйте:
<code>
ls /usr/lib | less
</code>
Достигнув конца документа, нажмите клавишу Q, чтобы вернуться в
командную строку. Вы также можете предварительно отсортировать
этот список по убыванию, например, таким образом:
<code>
ls /usr/lib | sort -r | less
</code>
Краеугольный камень философии Unix заключается в том, чтобы каждая программа делала что-то одно по-настоящему хорошо, позволяя
использовать свой вывод как ввод другой программы. Использование
каналов позволяет провести этот принцип в жизнь, создавая очень
эффективные цепочки команд.
Теперь, разузнав, как работают grep и каналы, сведем их вместе для
поиска того самого отчета и отправим его нашему коллеге:
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat report1.txt | mail colleague@work.com
</code>
Миссия завершена!

==== Мини-проект: команды для умных ====
Есть несколько общих команд, о которых
полезно знать. Привожу некоторые из них без
объяснений; эти команды можно использовать
независимо от дополнительных опций.
Наберите их и посмотрите на результат.
date df
date +%D free
date +%T du
cal top
cal 1066 ps

Через месяц Moнтирование, создание резервных копий, распаковка файлов из tar и zip.

LXF97:Bash

2008-03-08T17:38:38Z

OWeRQ:

== Bash: Используем командную строку ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользователям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вошли в систему; очень удобно, когда вы работаете с несколькими учетными записями, используемыми для решения различных задач, и постоянно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напечатав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечатали. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может пригодиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегодня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

=== Часть 1: По Grep’у! ===
Вот теперь повеселимся! Grep – команда, которая находит слова в
файлах. Охотно сказала бы, что ее название произошло от слова
"поиск" по-клингонски, но это было бы неправдой и только укрепило бы стереотип, что все технари любят Star Trek! На самом деле
название команды – сокращение от "Глобальный Парсер Регулярных
Выражений" (Global Regular Expression Parser), что означает "глобальный поиск строк, соответствующих регулярному выражению, и их
вывод на экран". Название команды происходит от команды текстового
редактора ed g/re/p, выполняющей подобные действия.
Начнем с создания специального каталога, где будем размещать новые
файлы. Чтобы убедиться, что каталог создан, используйте команду ls.
<code>
probert@ubuntu:~$ mkdir Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Откроем текстовый редактор и создадим новый файл report1.txt:
<code>
probert@ubuntu:~$ pico report1.txt
</code>
Pico – это текстовый редактор, который я использовала при написании
этой статьи. В дистрибутив Linux включено несколько текстовых редакторов; выбор одного из них определяется лишь вашими предпочтениями и наличием у редактора специальных функций, которые помогут
в решении именно вашей задачи. Когда текстовый редактор откроется,
напечатайте слово CompanyABC. Затем точно так же создайте второй
файл с именем report2.txt, который будет содержать слово companyabc.
Закончив, введите команду ls, и вы увидите примерно такой список:
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music report1.txt report2.txt Work
</code>
Обратите внимание, что файлы, которые мы создали, находятся рядом
с каталогом Work. Давайте переместим их в нужный каталог:
<code>
probert@ubuntu:~$ mv report*.txt /home/probert/Work
probert@ubuntu:~$ ls
Bin Desktop Examples LAN Music Work
</code>
Звездочка (*) – это специальный символ, который позволяет нам
делать все, что мы хотим, с файлами, название которых начинается со
слова report; каждый из таких файлов включается в команду. У меня
есть правила именования файлов и разделения их на категории, кото-
рых я строго придерживаюсь. Например, названия всех файлов отчетов
начинаются со слова report, счетов – со слова invoice и т.д. Пускай это
выглядит как ритуальные действия безнадежно больного ОКР, зато при
наличии методичного подхода нужные вещи находятся очень быстро!
Переместимся в каталог Work и снова используем ls, чтобы убедиться,
что все файлы перемещены:
<code>
probert@ubuntu:~$ cd Work
probert@ubuntu:~/Work$ ls
report1.txt report2.txt
</code>
Сейчас мы сделаем следующий шаг в поисках этого крайне важного
файла для нашего коллеги. Команда grep обладает множеством опций
(их список выведет команда man grep). Опция -r позволяет выполнить
рекурсивный поиск файлов, начиная с названного каталога, а опция -i
выполнит поиск без учета регистра. Попробуйте следующие команды с
опцией -i и без -i и посмотрите, как это повлияет на результаты поиска.
<code>
probert@ubuntu:~/Work$ grep -r -i ‘CompanyABC’ /home/
probert/Work
</code>
Результат будет примерно таким:
<code>
/home/probert/Work/report1.txt:CompanyABC
/home/probert/Work/report2.txt:companyabc
</code>
Итак, мы нашли этот неуловимый файл; что же дальше?

=== Часть 2: Стандартный ввод-вывод ===
Стандартный ввод/вывод позволяет вводить данные в программу из
любого источника и выводить данные в любой источник. Таким образом, можно направить вывод одной команды непосредственно на ввод
другой команды... правда, мило? Linux предоставляет три канала ввода/вывода, более известных как потоки ввода/вывода. По умолчанию стандартный ввод подразумевает клавиатуру, стандартный вывод – экран.
Третий поток ввода/вывода – это на самом деле поток вывода для сообщений об ошибках, предупреждений и оповещений: так легче отличить
сообщения об ошибках от остальных сообщений. Поток ошибок обычно
также выводится на экран, но (как и каждый из трех стандартных потоков) может быть перенаправлен. Этим мы сейчас и займемся.
Есть два основных способа перенаправления потоков данных; мы
можем использовать > или | (перенаправление и каналы соответственно). Если нужно просто направить стандартный вывод в файл, можно
напечатать команда > файл. Давайте попробуем это на реальном примере: найдем все файлы с именем passwd в каталоге /etc. Наберите
<code>
find /etc -name passwd
</code>
Результат будет примерно таким (он зависит от особенностей вашего
дистрибутива Linux):
<code>
probert@ubuntu:~$ find /etc -name passwd
find: /etc/ssl/private: Permission denied
/etc/passwd
/etc/pam.d/passwd
find: /etc/cups/ssl: Permission denied
</code>
Обратите внимание, что команда генерирует как стандартный поток
вывода, так и поток ошибок. Сейчас мы создадим файл findresult и
перенаправим стандартный поток вывода в этот файл, оставив на экране только ошибки.
<code>
probert@ubuntu:~$ find /etc -name passwd > findresult
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Перенаправим эти ошибки в другой файл, finderrors, используя 2>.
<code>
probert@ubuntu:~$ find /etc -name passwd 2> finderrors
/etc/passwd
/etc/pam.d/passwd
</code>
Наберите ls, и вы получите результат, похожий на мой.
<code>
probert@ubuntu:~$ ls
Bin Desktop Examples finderrors findresult LAN Music
</code>

==== Помощь по grep (вырезка) ====
Поскольку grep производит поиск соответствий по шаблонам, вы
должны предоставить ему регулярное выражение для этого шаблона.
Регулярные выражения бывают простыми и сложными. Наиболее распространенные (и простые) типы регулярных выражений выглядят так:
*abc Соответствует строкам, которые содержат “abc” в любом месте.
*^abc Соответствует строкам, начинающимся с “abc”.

Чтобы прочитать содержимое этих файлов, можно открыть их в текстовом редакторе pico:
<code>
probert@ubuntu:~$ pico findresult
</code>
Я предпочитаю просматривать небольшие файлы с помощью команды
cat. Ниже я использовала эту команду для просмотра результатов поиска в файлах findresult и finderrors.
<code>
probert@ubuntu:~$ cat findresult
/etc/passwd
/etc/pam.d/passwd
probert@ubuntu:~$ cat finderrors
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
</code>
Вы также можете добавить информацию в файл с помощью команды
>>. Давайте перенаправим стандартный вывод, чтобы добавить информацию в наш первый файл findresult следующим образом:
<code>
probert@ubuntu:~$ find /etc -name passwd 2>> findresult
</code>
Вы можете снова проверить результаты с помощью команды cat
findresult. Второй способ перенаправления потоков – вывод одной
команды прямо на вход другой (канализация). Давайте проверим
содержимое каталога /usr/lib, где находятся объектные файлы, библиотеки и системные двоичные файлы. В моем каталоге /usr/lib примерно полторы тысячи файлов – многовато, чтобы прокручивать этот
список один за другим! Если мы перенаправим вывод ls на ввод команды less, то получим список, в котором можно перемещаться по страницам, в удобном для нас темпе. Попробуйте:
<code>
ls /usr/lib | less
</code>
Достигнув конца документа, нажмите клавишу Q, чтобы вернуться в
командную строку. Вы также можете предварительно отсортировать
этот список по убыванию, например, таким образом:
<code>
ls /usr/lib | sort -r | less
</code>
Краеугольный камень философии Unix заключается в том, чтобы каждая программа делала что-то одно по-настоящему хорошо, позволяя
использовать свой вывод как ввод другой программы. Использование
каналов позволяет провести этот принцип в жизнь, создавая очень
эффективные цепочки команд.
Теперь, разузнав, как работают grep и каналы, сведем их вместе для
поиска того самого отчета и отправим его нашему коллеге:
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat report1.txt | mail colleague@work.com
</code>
Миссия завершена!

==== Мини-проект: команды для умных ====
Есть несколько общих команд, о которых
полезно знать. Привожу некоторые из них без
объяснений; эти команды можно использовать
независимо от дополнительных опций.
Наберите их и посмотрите на результат.
date df
date +%D free
date +%T du
cal top
cal 1066 ps

Через месяц Moнтирование, создание резервных копий, распаковка файлов из tar и zip.

LXF97:Bash

2008-03-08T17:20:35Z

OWeRQ: Новая: == Bash: Используем == ''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт''' расс...

== Bash: Используем ==
''Часть 2 Хотите проводить в командной строке больше времени? '''Рэйчел Проберт'''
расскажет о grep, pipe и других командах, которые обязательно надо знать.''

В прошлый раз мы говорили о действиях, потенциально способных
отобрать много времени: например, необходимо быстро найти отчет,
написанный когда-то давно. Вы забыли имя файла, но помните, что
темой отчета было соглашение с компанией ABC. После обнаружения
документа его содержимое нужно отправить коллеге или шефу.
<code>
grep -r -i -H CompanyABC /home/rjprobert/work
cat filename | mail colleague@work.com
</code>
Для начала мы разомнемся с помощью нескольких команд для
опытных пользователей. Они вряд ли пригодятся обычным пользова-
телям для каждодневной работы, но если вы администратор системы
и устанавливаете программы для своих пользователей, значение этих
команд повышается.
Команда whoami не вовлечет вас в философские дискуссии по
самопознанию, но напомнит, под каким именем пользователя вы вош-
ли в систему; очень удобно, когда вы работаете с несколькими учетны-
ми записями, используемыми для решения различных задач, и посто-
янно переключаетесь между ними. Похожая команда, whatis, позволит
понять, что делает та или иная программа. В Linux сотни программ, и
невозможно запомнить, что делает каждая из них. Например, напеча-
тав whatis grep, вы увидите:
<code>
grep (1) - print lines matching a pattern
</code>
Команда whereis поможет найти другие нужные вам команды или
программы. Если вы загружаете из Интернета программу, для работы
которой нужна другая программа, вам захочется узнать, установлена
ли она в вашей системе. Чтобы выяснить местонахождение программы
и ее man-страницы, наберите whereis [имя программы]. Так, например,
находится расположение популярного текстового редактора vi:
<code>
whereis vi
</code>
Echo – небольшая команда, повторяющая все, что вы ни напечата-
ли. Например, если набрать echo hello, на экране появится слово "hello".
Вообще говоря, обычно это делать незачем: команда echo может при-
годиться вам в будущем, если вы начнете писать скрипты. (Скрипт – это
небольшая программа, позволяющая выполнить несколько команд за
один раз.) В скриптах echo может использоваться для отображения
действий скрипта в каждый момент времени, или чтобы попросить
пользователя что-нибудь сделать, например, ввести текст.
Команда last выведет список пользователей, заходивших сегод-
ня в систему, и терминалы, которые они используют (использовали).
Набрав exit, вы завершите сеанс работы с терминалом. Если нужно
зайти в систему под другим пользователем, используйте вместо нее
команду logout.

----
в процессе написания..

LXF97

2008-03-08T11:35:41Z

OWeRQ: /* Linux Format 97 (10), Октябрь 2007 */

==Linux Format 97 (10), Октябрь 2007==

=== Обзоры ===
* [[LXF97:eSys PC|eSys PC]]
* [[LXF97:Google Desktop|Google Desktop]]
* [[LXF97:Yellow Dog PS 3|Yellow Dog PS 3]]
* [[LXF97:MailEnforcer 3.0|MailEnforcer 3.0]]
* [[LXF97:Paragon NTFS|Paragon NTFS]]

[[LXF97:Сравнение|Сравнение: IRC-клиенты]]

[[LXF97:Ubuntu|Битва за лучший Ubuntu]]

[[LXF97:Игры|Какова цена свободы?]]

[[LXF97:Пережить Slashdot-эффект|Пережить Slashdot-эффект]]

[[LXF97:OpenMoko|Что за штука? OpenMoko]]

[[LXF97:Служба доменных имен|Служба доменных имен]]

=== Учебники ===
* [[LXF97:Первые шаги|Первые шаги]]
Откладывай на завтра то, что можешь
сделать сегодня, но делай это с умом –
'''Энди Ченнел''' подскажет, как не навредить
и выкроить минутку для отдыха.

* [[LXF97:Bash|Bash]]
Сегодня '''Рэйчел Проберт''' познакомит вас
с командой grep и каналами, а также
даст пару советов, достойных
продвинутых пользователей.

* [[LXF97:Python|Python]]
Зачем мучиться с графическим
приложением, когда для сортировки
файлов можно использовать Python?
'''Ник Вейч''' покажет, как.

* [[LXF97:Командная строка|Командная строка]]
'''Крис Браун''' знает, как построить из
невзрачных кирпичей прекрасный
дворец. Соберите с виду бесполезные
утилиты в единое целое и наслаждайтесь
всей мощью Linux!

* [[LXF97:Mono|Mono]]
За приятной внешностью '''Пола Хадсона'''
скрывается убежденный параноик.
Зашифруйте с его помощью все самое
ценное – пока у вас еще есть такая
возможность...

* [[LXF97:Hardcore Linux|Hardcore Linux]]
Даже двенадцати тысячам пакетов
Gentoo не испугать '''Нейла Ботвика'''!
Получите максимум от этого
дистрибутива под его чутким
руководством.

* [[LXF97:Java|Java]]
Магия Java: всего на нескольких
страницах '''Александр Бабаев''' напишет
приличный почтовый клиент и простой
графический интерфейс к нему.

* [[LXF97:GtkSourceView|GtkSourceView]]
Каждый программист в своей жизни
должен написать текстовый редактор, и
желательно помощнее. '''Петр Семилетов'''
уже справился с этой задачей и готов
поделиться своим опытом.

* [[LXF97:Новая серия!|Новая серия!]]
Нет, вы не открыли по ошибке журнал
"Наш Сад"! '''Андрей Паскаль''' начинает
серию статей о свободной учетной
системе, доступной в Linux.

* [[LXF97:Hibernate|Hibernate]]
Не ждите, пока запустится система –
просто откройте ноутбук и продолжайте
работать! '''Сергей Яремчук''' посоветует,
как правильно пожелать вашему Linux
спокойной ночи.

* [[LXF97:Препресс в Linux|Препресс в Linux]]
Мы подобрались к самому
интересному – '''Александр Чернышов'''
запасся пленкой и готов к выходу на
офсет!

* [[LXF97:TeX|TeX]]
В течение месяца ломали голову, как
подружить Linux с любовно настроенной
в прошлый раз точкой доступа? '''Андрей
Боровский''' знает ответ.

[[LXF97:Ответы|Ответы]]

LXF97

2008-03-08T11:22:42Z

OWeRQ: Новая: ==Linux Format 97 (10), Октябрь 2007== === Обзоры === * eSys PC * Google Desktop * Yellow Dog PS 3 * [[...

==Linux Format 97 (10), Октябрь 2007==

=== Обзоры ===
* [[LXF97:eSys PC|eSys PC]]
* [[LXF97:Google Desktop|Google Desktop]]
* [[LXF97:Yellow Dog PS 3|Yellow Dog PS 3]]
* [[LXF97:MailEnforcer 3.0|MailEnforcer 3.0]]
* [[LXF97:Paragon NTFS|Paragon NTFS]]

=== Учебники ===
* [[LXF97:Первые шаги|Первые шаги]]
Откладывай на завтра то, что можешь
сделать сегодня, но делай это с умом –
'''Энди Ченнел''' подскажет, как не навредить
и выкроить минутку для отдыха.

* [[LXF97:Bash|Bash]]
Сегодня '''Рэйчел Проберт''' познакомит вас
с командой grep и каналами, а также
даст пару советов, достойных
продвинутых пользователей.

* [[LXF97:Python|Python]]
Зачем мучиться с графическим
приложением, когда для сортировки
файлов можно использовать Python?
'''Ник Вейч''' покажет, как.

* [[LXF97:Командная строка|Командная строка]]
'''Крис Браун''' знает, как построить из
невзрачных кирпичей прекрасный
дворец. Соберите с виду бесполезные
утилиты в единое целое и наслаждайтесь
всей мощью Linux!

* [[LXF97:Mono|Mono]]
За приятной внешностью '''Пола Хадсона'''
скрывается убежденный параноик.
Зашифруйте с его помощью все самое
ценное – пока у вас еще есть такая
возможность...

* [[LXF97:Hardcore Linux|Hardcore Linux]]
Даже двенадцати тысячам пакетов
Gentoo не испугать '''Нейла Ботвика'''!
Получите максимум от этого
дистрибутива под его чутким
руководством.

* [[LXF97:Java|Java]]
Магия Java: всего на нескольких
страницах '''Александр Бабаев''' напишет
приличный почтовый клиент и простой
графический интерфейс к нему.

* [[LXF97:GtkSourceView|GtkSourceView]]
Каждый программист в своей жизни
должен написать текстовый редактор, и
желательно помощнее. '''Петр Семилетов'''
уже справился с этой задачей и готов
поделиться своим опытом.

* [[LXF97:Новая серия!|Новая серия!]]
Нет, вы не открыли по ошибке журнал
"Наш Сад"! '''Андрей Паскаль''' начинает
серию статей о свободной учетной
системе, доступной в Linux.

* [[LXF97:Hibernate|Hibernate]]
Не ждите, пока запустится система –
просто откройте ноутбук и продолжайте
работать! '''Сергей Яремчук''' посоветует,
как правильно пожелать вашему Linux
спокойной ночи.

* [[LXF97:Препресс в Linux|Препресс в Linux]]
Мы подобрались к самому
интересному – '''Александр Чернышов'''
запасся пленкой и готов к выходу на
офсет!

* [[LXF97:TeX|TeX]]
В течение месяца ломали голову, как
подружить Linux с любовно настроенной
в прошлый раз точкой доступа? '''Андрей
Боровский''' знает ответ.

[[LXF97:Ответы|Ответы]]

LXF84:Unix API

2008-03-07T20:34:02Z

OWeRQ:

== Сигналы ==
''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения '''SIGKILL''' система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса '''SIG''', за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал '''SIGHUP''' (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал '''SIGHUP''' посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение '''SIGHUP''' демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал '''SIGINT''' (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш ''Ctrl-C'') .
*Сигнал '''SIGABRT''' (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал '''SIGKILL''' (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал '''SIGSEGV''' (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал '''SIGTERM''' (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение '''SIGTERM''' свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал '''SIGCHLD''' (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал '''SIGCHLD''' игнорируется.
*Сигнал '''SIGCONT''' (номер 18) возобновляет выполнение процесса, остановленного сигналом '''SIGSTOP'''. Сигнал '''SIGSTOP''' (номер 19) приостанавливает выполнение процесса. Как и '''SIGKILL''', этот сигнал не возможно перехватить или игнорировать.
*Сигнал '''SIGTSTP''' (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал '''SIGIO/SIGPOLL''' (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, '''SIGUSR1''' (в Linux – номер 10) и '''SIGUSR2''' (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).
<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf ("Terminating\n");
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf("My pid is %i\n", getpid());
printf("Waiting...\n");
while(1)
sleep(1);
return EXIT_FAILURE;
}
</code>
Наша программа делает две вещи: обрабатывает сигнал '''SIGTERM''' (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала '''SIGTERM''' term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – '''SIGTERM''', может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу '''SIGTERM''' означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала '''SIGTERM'''. В принципе, вы можете придать сигналу '''SIGTERM''' совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик '''SIGTERM''' предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction.

Поля структуры '''sigaction''':
*sa_handler - Значение Указатель на функцию обработчик сигнала или константа
*sa_mask - Маска сигналов, блокируемых на время вызова обработчика
*sa_flags - Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа '''SIG_IGN''' указывает, что сигнал следует игнорировать, а константа '''SIG_DFL''' – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле '''sa_mask''' позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр '''sa_flags''' позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг '''SA_RESETHAND''' указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала '''SIGTERM'''. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал '''SIGTERM''' приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы '''SIGINT''' и '''SIGABRT''' – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа '''SIG_BLOCK''' указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа '''SIG_SETMASK''' указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа '''SIG_UNBLOCK''' указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал '''SIGHUP''' и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал '''SIGHUP''' вы можете с помощью консольной команды
<'''Полужирное начертание'''code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала '''SIGHUP''' (файл swdemo.c на компакт-диске):
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf("SIGHUP recieved\n");
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал '''SIGHUP''', распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf("Signal %i - %s\n", sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала '''SIGTERM''' (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме '''SIGTERM''' (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры '''sigaction''':
*PID > 1 - Сигнал посылается процессу с соответствующим PID.
*PID == 0 - Сигнал посылается всем процессам из той же группы, что и процесс-источник.
*PID < 0 - Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID.
*PID == 1 - Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
#D. P. Bovet, M. Cesati, '''Understanding the Linux Kernel, 3rd Edition, O’Reilly''', 2005
#W. R. Stevens, S. A. Rago, '''Advanced Programming in the UNIX® Environment: Second Edition''', Addison Wesley Professional, 2005

'''Через месяц''' Мы породим монстра... то есть демона.

LXF84:Unix API

2008-03-07T20:32:13Z

OWeRQ:

== Сигналы ==
''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения '''SIGKILL''' система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса '''SIG''', за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал '''SIGHUP''' (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал '''SIGHUP''' посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение '''SIGHUP''' демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал '''SIGINT''' (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш ''Ctrl-C'') .
*Сигнал '''SIGABRT''' (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал '''SIGKILL''' (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал '''SIGSEGV''' (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал '''SIGTERM''' (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение '''SIGTERM''' свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал '''SIGCHLD''' (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал '''SIGCHLD''' игнорируется.
*Сигнал '''SIGCONT''' (номер 18) возобновляет выполнение процесса, остановленного сигналом '''SIGSTOP'''. Сигнал '''SIGSTOP''' (номер 19) приостанавливает выполнение процесса. Как и '''SIGKILL''', этот сигнал не возможно перехватить или игнорировать.
*Сигнал '''SIGTSTP''' (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал '''SIGIO/SIGPOLL''' (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, '''SIGUSR1''' (в Linux – номер 10) и '''SIGUSR2''' (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).
<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf ("Terminating\n");
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf("My pid is %i\n", getpid());
printf("Waiting...\n");
while(1)
sleep(1);
return EXIT_FAILURE;
}
</code>
Наша программа делает две вещи: обрабатывает сигнал '''SIGTERM''' (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала '''SIGTERM''' term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – '''SIGTERM''', может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу '''SIGTERM''' означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала '''SIGTERM'''. В принципе, вы можете придать сигналу '''SIGTERM''' совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик '''SIGTERM''' предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction.

Поля структуры '''sigaction''':
*sa_handler - Значение Указатель на функцию обработчик сигнала или константа
*sa_mask - Маска сигналов, блокируемых на время вызова обработчика
*sa_flags - Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа '''SIG_IGN''' указывает, что сигнал следует игнорировать, а константа '''SIG_DFL''' – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле '''sa_mask''' позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр '''sa_flags''' позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг '''SA_RESETHAND''' указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа '''SIG_BLOCK''' указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа '''SIG_SETMASK''' указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа '''SIG_UNBLOCK''' указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал '''SIGHUP''' и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал '''SIGHUP''' вы можете с помощью консольной команды
<'''Полужирное начертание'''code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала '''SIGHUP''' (файл swdemo.c на компакт-диске):
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf("SIGHUP recieved\n");
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал '''SIGHUP''', распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf("Signal %i - %s\n", sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала '''SIGTERM''' (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме '''SIGTERM''' (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры '''sigaction''':
*PID > 1 - Сигнал посылается процессу с соответствующим PID.
*PID == 0 - Сигнал посылается всем процессам из той же группы, что и процесс-источник.
*PID < 0 - Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID.
*PID == 1 - Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
#D. P. Bovet, M. Cesati, '''Understanding the Linux Kernel, 3rd Edition, O’Reilly''', 2005
#W. R. Stevens, S. A. Rago, '''Advanced Programming in the UNIX® Environment: Second Edition''', Addison Wesley Professional, 2005

'''Через месяц''' Мы породим монстра... то есть демона.

LXF84:Java

2008-03-07T19:54:40Z

OWeRQ: Отмена правки № 71 участника OWeRQ (обсуждение)

== Сказка Java ==
''ЧАСТЬ 1: От кофеварок до промышленных серверов и биллинговых систем - Java можно встретить буквально везде. Начните изучение этой технологии вместе с '''Антоном Черноусовым'''.''

Начиная ряд статей о программировании на объектно-ориентированном языке Java, хотел бы выразить свое мнение относительно корпоративного рынка разработки программного обеспечения, на котором в данный момент борются за лидерство два гиганта, две платформы: J2EE и .NET.

В основе платформы J2EE лежит язык программирования Java – приложения, созданные с его помощью, являются кроссплатформенными, сам язык, средства разработки и технология активно поддерживаются многими корпорациями: Sun, Google, IBM, Oracle, BEA. Платформа пользуется большой популярностью и среди компаний, ориентированных на OpenSource, таких как Apache Foundation. В противовес J2EE, корпорация Microsoft предлагает свою технологию .NET, которая является колоссом, построенным на мощи программного обеспечения Microsoft.

Сегодня еще нельзя сказать, какая технология станет доминирующей, и, возможно, от вас зависит скорость распространения современной кроссплатформенной технологии создания приложений J2EE и языка программирования Java.

Предложенные вашему вниманию уроки позволят овладеть основными понятиями ООЯ Java и создавать различные приложения с его помощью. Рассмотрев основы языка, мы сможем изучить типовые решения (паттерны) в программировании и приступить к изучению J2EE.
В первом уроке мы создадим свое первое приложение и разберемся с основными понятиями: инкапсуляция, наследование и полиморфизм. Для выполнения этого урока нам понадобится пакет Java SDK 1.5, текстовый редактор и немного терпения.
=== Героический объект ===
Приступая к этой серии материалов, я вспомнил, что, как правило, изучение языков программирования начинается с написания приложения «Hello World!», но такой прием настолько изъезжен, что я намереваюсь предложить пример поинтереснее: мы напишем приложение, рассказывающее сказку. Основа приложения – два класса. Каждый класс содержит члены двух видов: атрибуты и методы. Атрибуты – это данные, принадлежащие самому классу. Совокупное значение атрибутов определяет состояние объекта или класса. Метод – это последовательность операторов, изменяющих значения атрибутов и, как следствие, состояние класса или объекта.

В каждой интересной сказке должен быть свой герой. Предлагаю взглянуть на класс, который реализует нашего героя. Итак, по порядку. Следующий код необходимо сохранить в файл '''FirstHero.java.'''
<code>
public class FirstHero {
private String quest;
public FirstHero(String Quest) {
this.quest = Quest;
}
public void setQuest(String Quest){
this.quest = Quest;
};
public String getQuest(){
return quest;
};
}
</code>
Расположение одного класса в одном файле считается хорошим тоном среди программистов на Java – так что приучайтесь к нему сразу. Имя файла должно совпадать с названием класса, расширение у файла – '''.java.'''

Первый созданный нами класс содержит один защищенный атрибут (private – модификатор, зарезервированное слово, которое обеспечивает возможность обращения к члену класса только внутри класса) и три открытых метода (public – модификатор, зарезервированное слово, которое обеспечивает возможность обращения к члену класса из любого другого класса.). Хорошо спроектированный класс не имеет открытых атрибутов, что позволяет быть уверенным в правильной работе с ними. Доступ к защищенным атрибутам осуществляется через открытые методы. Такая организация класса позволяет разработчику через методы реализовать различные проверки и исключить неправильное поведение объекта. Класс представляет собой объединение атрибутов и методов в единое целое – подобное объединение называется инкапсуляцией.

Вы можете заметить, что первый метод (третья строка представленного ранее листинга) имеет то же название, что и класс – FirstHero. Такой метод называется конструктором. Конструктор – это метод, который используется при создании экземпляра класса для задания внутреннего состояния объекта, например:
<code>
FirstHero ourNewHero = new FirstHero(“Спасти царевну”);
</code>
Единственный атрибут нашего класса quest имеет тип строка (String). Для установки значения атрибута quest используется метод
setQuest. Метод setQuest является public и не возвращает никакого значения. Для обозначения методов, не возвращающих значение, используется зарезервированное слово void. Для вызова метода setQuest необходим обязательный параметр: Quest типа String. Для получения значения атрибута quest используется метод getQuest, который вызывается без параметров, является открытым и возвращает значение типа String.

Вызов описанных выше методов для объекта ourNewHero осуществляется следующим образом:
<code>
ourNewHero.getQuest();
ourNewHero.setQuest(“какая-то строка”);
</code>
Парные методы, различающиеся приставками set и get, принято создавать для работы с закрытыми атрибутами. Это обязательное
условие для реализации объекта в виде JavaBean. Что такое JavaBean, мы обсудим позже – сейчас запомните, что такое наименование методов позволяет избавиться от ряда проблем в больших системах.

Приступим к написанию самой сказки. Возьмите следующий код и поместите его в файл '''Story.java'''.

<code>
public class Story {
public static void main(String[] args) {
FirstHero ourNewHero = new FirstHero(“Спасти царевну “);
System.out.println(“Наш герой хочет отправиться в путь и “ + ourNewHero.getQuest());
}
}
</code>

Это класс Story, он имеет всего один метод main, который является статичным (static-методы и переменные принято называть переменными класса и методами класса, т.к. они общие для всех объектов) и используется для работы с классом в целом. Метод main – это стартовая точка для запуска программы, с которой начинается интерпретация кода.

В ходе интерпретации метода main создается новый объект ourNewHero, а также вызывается метод println объекта out, который обеспечивает вывод в стандартный выходной поток строковойпеременной.

Откомпилируем код и увидим, что у нас получилось. Для компиляции переместитесь в каталог, где вы разместили свои файлы и выполните следующую команду:
<code>
# javac *.java
</code>
При желании вы можете откомпилировать классы по отдельности, следующим образом:
<code>
# javac Story.java
# javac FirstHero.java
</code>
В итоге вы получите два файла '''Story.class''' и '''FirstHero.class'''. Теперь посмотрим на результат:
<code>
# java Story
Наш герой хочет отправиться в квест и Спасти царевну
</code>

Первая программа на Java готова и работает! Вы создали два класса и научились выводить информацию в консоль. Но мы забыли о
комментариях...

Комментарии бывают нескольких типов:
*Строчные начинаются с символа // и длятся до окончания строки.
*Многострочные комментарии заключаются между /* и */.
*Комментарии JavaDoc – это многострочные комментарии, заключенные между /** и */, например:

<code>
/**
* Класс является прототипом объекта “герой”
* @author Chernousov Anton
* @version 0.1
*/
public class FirstHero {
…
/**
* Метод предназначен для установки внутренней переменной
quest
* в значение Quest.
* У этого метода один параметр
* @param Quest это переменная означает задание для Героя
*/
public void setQuest(String Quest)
…
</code>

Комментарии JavaDoc предназначены для формирования документации к проекту из исходных кодов. Если добавить в файл '''FirstHero.java''' только что приведенные строки, то с помощью команды '''javadoc -author -version *.java''' можно сформировать документацию к нашему проекту.

JavaDoc позволяет создавать подробную документацию, которая просто необходима для любого достаточно крупного проекта.
=== Наследование, интерфейсы и их реализация ===
Наша сказка написана, но что делать, если проект большой и над ним работает много людей? Как реализовать одновременное программирование разных классов так, чтобы результаты, полученные отдельными разработчиками, можно было без труда соединить в единое целое? Для решения этой задачи, а также задачи множественного наследования в Java существуют интерфейсы – interface. Но обо всем по порядку.

Наследование – это одна из парадигм программирования, которая связана с инкапсуляцией. Суть наследования заключается в следующем: если есть класс, инкапсулирующий в себе некоторые атрибуты и методы, то класс, наследующий его, автоматически наследует все его атрибуты и методы.
<code>
public class SecondHero extends FirstHero{
public SecondHero(String Quest) {
super(Quest + “ Несмеяну”);
}
}
</code>
Расположенный выше код объявляет класс SecondHero, который с помощью зарезервированного слова extends наследует (расширяет) класс FirstHero. В Java класс может наследовать (расширять)только один класс. При наследовании класса FirstHero, содержащего
конструктор, обязательно требуется переопределить его (например, как это делается в методе SecondHero). При выполнении оператора super(Quest) будет вызван аналогичный метод из суперкласса (класс-родителя). Строкой super(Quest + “Несмеяну”) мы переопределяем поведение конструктора. Естественно, класс SecondHero может содержать новые атрибуты и методы.

Для проверки механизма наследования сохраните приведенный текст класса SecondHero в файл '''SecondHero.java''' и в файле '''Story.java''' измените имя класса FirstHero на SecondHero. Откомпилируйте и запустите программу, в результате вы должны увидеть следующее:
<code>
# java Story
Наш герой хочет отправиться в путь и Спасти царевну Несмеяну
</code>
При разработке программы, перед тем, как приступить к программированию, сначала проводится процесс проектирования (например, через UML-нотации). В результате проектирования появляется документация к проекту, а также спецификации классов. Интерфейс – это явно указанная спецификация набора методов, которые должны быть представлены в классе, реализующий эту спецификацию. В серьезном проекте на момент начала программирования перед программистом оказываются интерфейсы, которые он должен реализовать в классах.

Интерфейс в Java – это специальный класс, в котором отсутствует реализация! Давайте напишем интерфейс для нашего класса FirstHero. Следует скопировать следующий далее код и поместить его в файл '''Hero.java''' – именно этот интерфейс мы будет использован далее. Как вы видите, в отличие от других классов, интерфейс объявляется с помощью зарезервированного слова interface. В нашем случае интерфейс представляет собой следующий набор методов:
<code>
public interface Hero {
public void setQuest(String Quest);
public String getQuest();
}
</code>
Чтобы класс FirstHero реализовывал интерфейс Hero, необходимо изменить первую строчку в файле '''FirstHero.java''' на public class FirstHero implements Hero {. Интерфейс может наследовать (расширять) множество других интерфейсов. Наример:
<code>
public interface Lord {
public String sendToQuest();
public void setBodyguard(Hero hisHero);
public Hero getBodyguard();
}

public interface King extends Hero, Lord{
public void setWife (String PrincesName);
public String getWife();
}
</code>
Класс может одновременно наследовать класс и реализовывать один или несколько интерфейсов. Например, как в классе LandLord,
который наследует класс FirstHero и реализует интерфейс Lord:
<code>
public class LandLord extends FirstHero implements Lord{
private Hero bodyguard;
public LandLord(String Quest, Hero hisHero) {
super(Quest);
this.bodyguard = hisHero;
}
public String sendToQuest() {
bodyguard.setQuest(this.getQuest());
return null;
}
public void setBodyguard(Hero hisHero) {
this.bodyguard = hisHero;
}
public Hero getBodyguard() {
return bodyguard;
}
}
</code>
Чтобы окончательно закрыть тему наследования, необходимо поговорить про абстрактные классы – те, что занимают промежуточное
место между интерфейсами и реальными классами. Объявление абстрактного класса или метода выполняется с помощью специального
слова abstract:
<code>
abstract public class Knight
</code>
Абстрактный класс представляет собой неполную реализацию всех объявленных методов, и его можно наследовать, как и любой из классов. Обязательным условием при наследовании является полная реализация абстрактных методов.

=== Полиморфизм ===
Полиморфизм – это концепция, реализованная в Java, которая позволяет одному и тому же объекту выступать в разных формах. Например, экземпляр класс LandLord можно использовать как объект класса FirstHero. Это стало возможным благодаря тому, что класс LandLord наследует класса FirstHero.

=== Перегруженные методы ===
Иногда при создании сложных (и не очень) систем есть необходимость реализовать два различных метода, названых одинаково – это возможно с помощью перегруженных (overloading) методов. Выбор реализации зависит от типа объектов, переданных в качестве параметров.
<code>
public class GreatKing extends LandLord implements King{
private String wife;
private boolean theftedWife;

public GreatKing(String Quest, Hero hisHero) {
super(Quest, hisHero);
}

public void setWife(String PrincesName) {
this.wife = PrincesName;
this.theftedWife = false;
}

public String getWife() {
if (theftedWife){return null;}
else{ return wife;}
}

public String getWife(boolean flag) {
if (flag){ this.theftedWife = true;}
return wife;
}
}
</code>
В представленном классе GreatKing существуют две реализации перезагруженного метода getWife, которые можно вызвать следующим образом:
<code>
GreatKing ourKing = new GreatKing(“Править мудро”, (Hero) new FirstHero(“Охранять господина”));
String hisWife = ourKing.getWife();
String theftedHisWife = ourKing.getWife(true);
</code>

=== Вместо заключения ===
Ну вот, мы создали всех героев. Разместите интерфейсы Lord, King, а также классы LandLord и GreatKing в соответствующих файлах.
Немного измените класс Story, чтобы завершить сказку:
<code>
public class Story {
public static void main(String[] args) {
// создадим наших героев
Hero ourNewHero = (Hero) new FirstHero(“Спасити царевну”);
GreatKing ourKing = new GreatKing(“Править мудро”, (Hero) new FirstHero(“Охранять господина”));
LandLord ourNewLandLord = new LandLord(“Похитить царевну”, (Hero) new FirstHero(“Охранять господина”));
// Женим нашего короля
ourKing.setWife(“Несмеяна”);
// И начнем повествование
System.out.println(“Жил был мудрый король, и должен был он “ + ourKing.getQuest());
System.out.println(“Была у него жена, и звали ее “ + ourKing.getWife());
System.out.println(“Был в королевстве коварный Визирь и хотел он “ + ourNewLandLord.getQuest());
System.out.println(“И сделал это”);
String wife = ourKing.getWife(true);
//
System.out.println(“А наш герой жаждал “ + ourNewHero.getQuest() + “ ..и добился этого”);
ourKing.setWife(wife);
System.out.println(“Король был счастлив.”);
System.out.println(“Ну а что случилось дальше вы можете придумать сами...”);
}
}
</code>
Откомпилируйте и насладитесь результатом выполнения урока.

В следующей статье мы поговорим о простых числах и других типах, вычислениях, циклах, массивах и списках.

LXF84:Unix API

2008-03-07T17:42:47Z

OWeRQ:

== Сигналы ==
''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf ("Terminating\n");
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf("My pid is %i\n", getpid());
printf("Waiting...\n");
while(1)
sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды
<code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf("SIGHUP recieved\n");
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf("Signal %i - %s\n", sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
#D. P. Bovet, M. Cesati, '''Understanding the Linux Kernel, 3rd Edition, O’Reilly''', 2005
#W. R. Stevens, S. A. Rago, '''Advanced Programming in the UNIX® Environment: Second Edition''', Addison Wesley Professional, 2005

'''Через месяц''' Мы породим монстра... то есть демона.

LXF84:Java

2008-03-07T17:35:43Z

OWeRQ:

== Сигналы ==
''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf ("Terminating\n");
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf("My pid is %i\n", getpid());
printf("Waiting...\n");
while(1) sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды
<code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf("SIGHUP recieved\n");
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf("Signal %i - %s\n", sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
#D. P. Bovet, M. Cesati, '''Understanding the Linux Kernel, 3rd Edition, O’Reilly''', 2005
#W. R. Stevens, S. A. Rago, '''Advanced Programming in the UNIX® Environment: Second Edition''', Addison Wesley Professional, 2005

'''Через месяц''' Мы породим монстра... то есть демона.

LXF84:Unix API

2008-03-07T17:33:37Z

OWeRQ:

== Сигналы ==
''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf ("Terminating\n");
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf("My pid is %i\n", getpid());
printf("Waiting...\n");
while(1) sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды
<code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf("SIGHUP recieved\n");
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf("Signal %i - %s\n", sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
#D. P. Bovet, M. Cesati, '''Understanding the Linux Kernel, 3rd Edition, O’Reilly''', 2005
#W. R. Stevens, S. A. Rago, '''Advanced Programming in the UNIX® Environment: Second Edition''', Addison Wesley Professional, 2005

'''Через месяц''' Мы породим монстра... то есть демона.

LXF84:Unix API

2008-03-07T17:31:34Z

OWeRQ:

== Сигналы ==
''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf (“Terminating\n”);
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf(“My pid is %i\n”, getpid());
printf(“Waiting...\n”);
while(1) sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды
<code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf(“SIGHUP recieved\n”);
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf(“Signal %i - %s\n”, sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
#D. P. Bovet, M. Cesati, '''Understanding the Linux Kernel, 3rd Edition, O’Reilly''', 2005
#W. R. Stevens, S. A. Rago, '''Advanced Programming in the UNIX® Environment: Second Edition''', Addison Wesley Professional, 2005

'''Через месяц''' Мы породим монстра... то есть демона.

LXF84:Unix API

2008-03-07T17:24:56Z

OWeRQ:

''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf (“Terminating\n”);
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf(“My pid is %i\n”, getpid());
printf(“Waiting...\n”);
while(1) sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды
<code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf(“SIGHUP recieved\n”);
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:
<code>
sigset_t sset;
int sig;
...
sigfillset(&sset);
sigdelset(&sset, SIGTERM);
sigprocmask(SIG_SETMASK, &sset, 0);
while(!sigwait(&sset, &sig))
printf(“Signal %i - %s\n”, sig, sys_siglist[sig]);
</code>
С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов
<code>
raise(sig);
</code>
эквивалентен вызову
<code>
kill(getpid(), sig);
</code>
Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
1. D. P. Bovet, M. Cesati, Understanding the Linux Kernel, 3rd Edition, O’Reilly, 2005 2. W. R. Stevens, S. A. Rago, Advanced Programming in the UNIX® Environment: Second Edition, Addison Wesley Professional, 2005

Через месяц Мы породим монстра... то есть демона.

LXF84:Unix API

2008-03-07T17:21:54Z

OWeRQ:

''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf (“Terminating\n”);
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf(“My pid is %i\n”, getpid());
printf(“Waiting...\n”);
while(1) sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте
<code>
kill <PID>
</code>
где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды
<code>
kill –s 1 <PID>
</code>
где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик
<code>
sigprocmask(SIG_BLOCK, &newset, 0);
while(!sigwait(&newset, &sig))
printf(“SIGHUP recieved\n”);
</code>
Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы: sigset_t sset; int sig; ... sigfillset(&sset); sigdelset(&sset, SIGTERM); sigprocmask(SIG_SETMASK, &sset, 0); while(!sigwait(&sset, &sig)) printf(“Signal %i - %s\n”, sig, sys_siglist[sig]); С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов raise(sig); эквивалентен вызову kill(getpid(), sig); Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
1. D. P. Bovet, M. Cesati, Understanding the Linux Kernel, 3rd Edition, O’Reilly, 2005 2. W. R. Stevens, S. A. Rago, Advanced Programming in the UNIX® Environment: Second Edition, Addison Wesley Professional, 2005

Через месяц Мы породим монстра... то есть демона.

LXF84:Unix API

2008-03-07T17:13:32Z

OWeRQ: Новая: ''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но при всем этом они незаменимы, ког...

''ЧАСТЬ 4: Сигналы традиционно считаются трудными в использовании, но
при всем этом они незаменимы, когда речь заходит о настоящих приложе-
ниях Unix. Разберитесь в них вместе с '''Андреем Боровским'''!''

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами межпроцессного взаимодействия заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие пользовательские программы. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания. Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима.

Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника. Номерам сигналов соответствуют константы, определенные в файле '''signal.h'''. Имена всех этих констант начинаются с префикса SIG, за которыми следует сокращенное название сигнала. Стандарт POSIX определяет две группы сигналов – «классические» сигналы Unix и сигналы реального времени. В отличие от классических сигналов сигналы реального времени всегда буферизуются, так что программа получит все посланные ей сигналы. В этой статье мы рассмотрим только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Мы же рассмотрим несколько наиболее интересных сигналов.
*Сигнал SIGHUP (номер 1) изначально был предназначен для того, чтобы информировать программу о потере связи с управляющим терминалом (терминалы часто подключались к системе с помощью модемов, так что название сигнала происходит от hung up – повесить трубку). Кроме того, сигнал SIGHUP посылается приложению в том случае, если процесс-лидер сессии завершил свою работу. Многие программы-демоны, у которых нет лидера сессии, также обрабатывают этот сигнал. В ответ на получение SIGHUP демон обычно перезапускается (или просто повторно читает файл конфигурации). По умолчанию программа, получившая этот сигнал, завершается.
*Сигнал SIGINT (номер 2) обычно посылается процессу, если пользователь терминала дал команду прервать процесс (обычно эта команда – сочетание клавиш Ctrl-C) .
*Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.
*Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.
*Сигнал SIGSEGV (номер 11) посылается процессу, который пытается обратиться к не принадлежащей ему области памяти. Если обработчик сигнала не установлен, программа завершается с сохранением на диске образа памяти.
*Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.
*Сигнал SIGCHLD (номер 17) посылается процессу в том случае, если его дочерний процесс завершился или был приостановлен. Родительский процесс также получит этот сигнал, если он установил режим отслеживания сигналов дочернего процесса и дочерний процесс получил какой-либо сигнал. По умолчанию сигнал SIGCHLD игнорируется.
*Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP. Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.
*Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).
*Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.
В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы).

Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл '''sigdemo.c''' на компакт-диске).

<code>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void term_handler(int i) {
printf (“Terminating\n”);
exit(EXIT_SUCCESS);
}

int main(int argc, char ** argv) {
struct sigaction sa;
sigset_t newset;
sigemptyset(&newset);
sigaddset(&newset, SIGHUP);
sigprocmask(SIG_BLOCK, &newset, 0);
sa.sa_handler = term_handler;
sigaction(SIGTERM, &sa, 0);
printf(“My pid is %i\n”, getpid());
printf(“Waiting...\n”);
while(1) sleep(1);
return EXIT_FAILURE;
}
</code>

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функциюобработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Единственным параметром нашего варианта функции-обработчика сигнала (в Unix-системах существует и другой вариант) является переменная типа int, в которой передается номер сигнала, вызвавшего обработчик. Нам этот номер не нужен, поскольку мы знаем, что только один сигнал – SIGTERM, может вызвать нашу функцию, однако, в принципе, ничто не мешает нам использовать одну функцию для обработки нескольких разных сигналов, и тогда параметр функции-обработчика будет иметь для нас смысл. Функция-обработчик не возвращает никакого значения, что вполне логично, так как она вызывается не нашей программой, а неким системным компонентом. Особый интерес представляет завершение программы из обработчика сигнала. Назначение обработчика сигналу SIGTERM означает, что «умолчательное» действие сигнала – завершение программы не будет выполняться автоматически, и нам необходимо (если, конечно, мы хотим, чтобы этот сигнал завершал программу) позаботиться обо всем явным образом. Если вы закомментируете вызов exit() в нашем примере, то увидите, что программа не будет завершаться по получении сигнала SIGTERM. В принципе, вы можете придать сигналу SIGTERM совершенно иной смысл, например, оповещать программу о наступлении времени вашей любимой телепередачи (или о выходе нового номера журнала Linux Format), однако назначать стандартным сигналам нестандартные действия категорически не рекомендуется. Обработчик SIGTERM предназначен для того, чтобы, по требованию системы или пользователя, программа могла быстро и элегантно закончить текущую задачу и завершить свое выполнение. Именно этим обработчик и должен заниматься. Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction. какого-либо сигнала. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте kill <PID> где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится. Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction(), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Поскольку нам, как правило, приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask(2), которая оперирует наборами сигналов (signal sets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction(), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа – sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset() инициализирует набор сигналов пустыми значениями, а функция sigfillset() устанавливает все возможные значения в наборе. Используемая нами функция sigaddset() добавляет значение сигнала в набор, а функция sigdelset() удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask(), которая выполняет блокировку и разблокировку сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды kill –s 1 <PID> где PID – идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном приложении, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Поля структуры sigaction
Поле sa_handler sa_mask sa_flags Значение Указатель на функцию обработчик сигнала или константа Маска сигналов, блокируемых на время вызова обработчика Дополнительные флаги

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться «умолчательным» обработчиком. В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() прерывается (возобновляет выполнение программы раньше срока) если возвращает управление обработчик sigprocmask(SIG_BLOCK, &newset, 0); while(!sigwait(&newset, &sig)) printf(“SIGHUP recieved\n”); Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы: sigset_t sset; int sig; ... sigfillset(&sset); sigdelset(&sset, SIGTERM); sigprocmask(SIG_SETMASK, &sset, 0); while(!sigwait(&sset, &sig)) printf(“Signal %i - %s\n”, sig, sys_siglist[sig]); С помощью вызовов sigfillset() и sigdelset() мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала. На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill() совпадает с семантикой одноименной команды ОС. У функции kill() два аргумента – PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill() как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2 демонстрирует поведение функции kill() в зависимости от значения PID:

Поля структуры sigaction
Поле PID > 1 PID == 0 PID < 0 Значение Сигнал посылается процессу с соответствующим PID. Сигнал посылается всем процессам из той же группы, что и процесс-источник. Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1 Сигнал посылается всем процессам системы.

Вызов raise(sig); эквивалентен вызову kill(getpid(), sig); Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill() можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill() вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен. Читателей, полюбивших обработку сигналов, я могу обрадовать тем, что мы рассмотрели далеко не все функции, связанные с сигналами. При изучении документации вас ждет еще много полезного и приятного, мы же закончим на этом наше знакомство с сигналами. Мы можем столкнуться с необходимостью обработки сигналов при программировании, например, процессов-демонов. Ими мы и займемся в следующей статье. LXF

Литература:
1. D. P. Bovet, M. Cesati, Understanding the Linux Kernel, 3rd Edition, O’Reilly, 2005 2. W. R. Stevens, S. A. Rago, Advanced Programming in the UNIX® Environment: Second Edition, Addison Wesley Professional, 2005

Через месяц Мы породим монстра... то есть демона.