Отправляет email-рассылки с помощью сервиса Sendsay

trap

Пытаюсь с trap разобраться.
Вот такой простейший скрипт:

trap 'echo sig' SIGCHLD
echo test

Казалось бы должно быть следующее. Первая строчка устанавливает обработчик
прерывания SIGCHLD. Вторая строчка порождает потомка печатающего test.
После завершения потомка должно пройти прерывание SIGCHLD и должен
сработать обработчик прерывания который напечатает sig. Т.е. результатом
этого скрипта должна быть печать двух строк:
test
sig
А печатается только
test

В чем ошибка? Предполагал что дело в том, что echo выполняется без
порождения процесса (самим bash), проверил - нет, если вместо
echo test подставить исполнение другого скрипта тоже sig на экране не
появляется.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Sat, 25 Oct 2003 10:55:19 +0000 (GMT) (#11663)

 

Ответы:

может это поможет?

цитата из ПРОГРАММИРОВАНИЕ НА shell (UNIX), А. Соловьев
5.8. Обработка прерываний ("trap")

Бывает необходимо защитить выполнение программы от
прерывания.
Наиболее часто приходится встречаться со следующими
прерываниями, соответсвующими сигналам:
0 - выход из интерпретатора,
1 - отбой (отключение удаленного абонента),
2 - прерывание от <Del>,
9 - уничтожение (не перехватывается),
15 - окончание выполнения.

Для защиты от прерываний существует команда "trap", имеющая
формат:

trap 'список команд' сигналы

Если в системе возникнут прерывания, чьи сигналы перечислены
через пробел в "сигналы", то будет выполнен "список команд",
после чего (если в списке команд не была выполнена команда
"exit") управление вернется в точку прерывания и продолжится
выполнение командного файла.

Например, если перед прекращением по прерываниям выполнения
какого то командного файла необходимо удалить файлы в "/tmp", то
это может быть выполнено командой "trap":

tarp 'rm /tmp/* ; exit 1' 1 2 15

которая предществует прочим командам файла. Здесь, после
удаления файлов будет осуществлен выход "exit" из командного
файла.
Команда "trap" позволяет и просто игнорировать прерывания,
если "список команд" пустой. Так например, если команда "cmd"
выполняется очень долго, а пользователь решил отключиться от
системы, то для продолжения выполнения этой команды можно
написать, запустив команду в фоновом режиме:

( trap '' 1; cmd )&
C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: myscri***@e*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Kolotov Alexandr Sat, 25 Oct 2003 10:05:45 +0400 (#11671)

 

Приветствую.

On Sat, 25 Oct 2003, Kolotov Alexandr wrote:

В общем то же самое что в man bash. Но кое-что более подробно
и с примерами (что всегда полезно). Так что спасибо.

Но почему у меня это не работает так и не понял. Может прерывания как-то
замаскированы?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Sat, 25 Oct 2003 13:51:02 +0000 (GMT) (#11691)

 

On Sat, 25 Oct 2003, Alexander S. Yurkov wrote:

Сколько ни экспериментирую, никак не получается что надо. И вообще как-то
все непонятно. Выяснил следующее. Прерывания 2 и 20 (клавиши CTRL-C и
CTRL-Z) ловятся всегда. Хоть нажатием клавиш генерируй эти прерывания,
хоть kill давай с другой консоли, хоть в том же скрипте пиши kill.
Прерывание 17 (как раз SIGCHLD) не ловится никогда, ни при одном из
этих двух (кроме нажатия клавиши, естественно) способов их генерации.
Остальные прерывания ловятся только если они сгенерированы с помощью kill
в том же скрипте (но никак не в скрипте вызваным этим скриптом или с
другой консоли). man bash перечитал вдоль и поперек про маскирование
прерываний ничего не нашел. Кто-нибудь может все это об'яснить?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Sat, 25 Oct 2003 16:47:30 +0000 (GMT) (#11720)

 

ИМХО, trap так и работает:
запускается скрипт, в начале его ставится trap, если в дальнейшем при выполнении
скрипта происходит одно из прерываний перечисленных в trap, то выполняется набор
команд определенных в аргументе trap.
Таким образом связь с потомком будет организована только в том случае, если этот
потомок пошлет вызывающему скрипту какой-нить сигнал, что было показано в
скрипте при обсуждении timeout - sleep после своего выполнения посылает
вызывающему скрипту сигнал SIGUSR1, а вызывающий скрипт перехватывает этот
сигнал с помощью trap.

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: myscri***@e*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Kolotov Alexandr Sat, 25 Oct 2003 16:25:17 +0400 (#11774)

 

On Sat, 25 Oct 2003, Kolotov Alexandr wrote:

набор

этот

Это само-собой. Но оказывается это не работает. Точнее, как
теперь уже выясняется, работает но не со всеми сигналами. Только что
выяснил что сигнал 10 (SIGUSR1) так проходит. Другие из скрипта в другой
(родитель) не ходят. Ходят только в пределах одного скрипта. Кроме 17
(SIGCHLD). Но дело даже не этом. При завершении потомка этот потомок сам
должен послать SIGCHLD родительскому процессу. Без каких-либо хлопот с
моей стороны. Но то ли не посылает, то ли сигнал не доходит. И почему
когда я даю kill -s sig pid с другой консоли, скрипт не реагирует на
сигнал, хотя перехват именно этого сигнала я прописал в нем (я их всех
прописал для экспериментов, с выводом разных текстов:-) )... Впрочем,
только что проверил: SIGUSR1 и тут проходит. А как же все остальные? Куда
они деваются? В общем не так страшно, стало ясно что просто надо
пользоваться не каким попало сигналом а SIGUSR1. Но хотелось бы
разобраться также, почему нет перехвата сигнала SIGCHLD.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Sat, 25 Oct 2003 19:09:27 +0000 (GMT) (#11791)

 

Приветствую.

Пока вопрос о trap в bash повис, задам еще один вопрос. Уже про fork &
exec. Почитал немного об этом в книге Bach-а. В общем очень изящный
механизм порождения новых процессов. Но интересно следующее.
Допустим такая програма (на "псевдоС" чтобы не отвлекаться на синтаксис):

/* Тут определение каких-то функций */

label:

/* тут идут какие-то коды*/

pid=fork();
if pid!=0
{
/* тут может быть все, что угодно, эта ветвь меня пока не
интересует*/
}
else
{
/*
Тут пока процесс не замещен на другой, работает копия исходного
процесса, в принципе можно
сделать, к примеру, goto label или вызвать какую-то функцию
определенную выше. Так или нет?
*/
exec(...);
/*
Теперь кодов после label фактически уже нет? И функций,
определенных в самом начале тоже? Процесс
замещен? Но что будет если написать далее, к примеру:
*/
goto label;
/*
Или вызвать какую-то функцию из определенных в самом начале?
Теоретически можно представить себе такие варианты (а других
нет?):
1. exec просто никогда не возращает управление в точку его
вызова. Так что что тут дальше написано все равно управления
никогда не получит.
2. exec в некоторых случаях (в каких?) возращает управление
но система отловит обращение по неправильным адресам.
3. Будут исполняться коды замещающего процесса (как уж адреса
наложатся) но какие - можно определить только изучая
ассемблерные листинги обеих програм.
4. Управление будет возращено в процесс-предок.

Это что можно себе представить теоретически. А как на самом
деле?
*/
}

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Sat, 25 Oct 2003 14:33:29 +0000 (GMT) (#11692)

 

на самом деле нужно читать POSIX-стандарты... а не задавать вопросы...
а именно:
Например, что написано в "Системное программирование в UNIX" Кейта Хевиленда
семейство вызовов exec преобразует вызывающий процесс, загружая новую программу
в его пространство памяти. Если вызов exec завершился успешно, то вызывающая
программа полностью замещается новой программой, которая запускается с начала.
Результата вызова можно рассматривать как запуск нового процесса, который при
этом сохраняет идентификатор запускающего процесса и по умолчанию наследует
файловые дескрипторы.
...
Успешный вызов exec не возвращает значения.
...
Если вызывающая программа сохраняет работоспособность и происходит возврат из
вызова exec, значит произошла ошибка. (ошибка создания нового процесса)
Я думаю, что ответил на вопросы 1,2,4, а про три подумай сам разумно ли это?
(не
являлось бы это дырой, похожей на buffer overflow?)

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: myscri***@e*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Kolotov Alexandr Sat, 25 Oct 2003 13:27:20 +0400 (#11698)

 

Приветствую.

On Sat, 25 Oct 2003, Kolotov Alexandr wrote:

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

Не возращает значения и не передает управления это не одно и тоже!
Но видимо (только по логике вещей) управления не передает тоже.

Ну мало ли чего неразумно... Не все в этом мире сделано разумно. Меня
интересует как сделано на самом деле. Впрочем, что разумно а что нет тоже
интересно.

IMHO не являлось бы. Потомок пользовательского процесса все равно не имеет
доступа к системной области напрямую. Только через системные вызовы.
Так что максимум одна пользовательская програма запорет другую
пользовательскую же. А вот buffer overflow - совсем другое дело, там в
режиме ядра буфер заполняется.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Sat, 25 Oct 2003 16:35:18 +0000 (GMT) (#11721)

 

Здравствуйте, Alexander.

Если есть желание узнать о ядре Линукс поподробнее, то на citforum.ru
(книги, статьи, документация) - есть неплохой разделам по ОСям, в том числе по
unix,
linux. Все на русском. Есть там и хауту, маны. Так вот имеется и
пару неплохих переводов по ядру линух. Читается легко и по размерам
приемлимо.

<cute>
- - -
</cute>

Ответить   Vadim Deev Sun, 26 Oct 2003 00:24:21 +0400 (#11844)

 

Здравствуйте!
У меня следующая проблема с XMMS.Большая часть названий
песен не читабельна,причем смена шрифтов не помогает.
При самой загрузке тегов на какое-то мгновение все нормально
а затем бардак в названиях.
Новую версию я не устанавливал.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   tee***@t*****.by Sun, 26 Oct 2003 11:08:09 +0300 (#11894)