Re: shell background job and trap SIGCHILD

[Oleksandr Gavenko]

On 2016-10-29, Dmitry Alexandrov wrote:

>> Проще command -v ${command}
>
> Пардон, для чего проще?  Для программной проверки, быть может, и так, но для 
> восприятия человеком (как здесь) — боюсь, что нет.
>
``which`` сторонняя утилита и ничего не говорит о том как поступает 
интерпретатор.

>> оно если с полным путем, то бинарь на диске,
>
> Да не обязательно с полным.  Если подать на вход относительный, то он его и 
> вернет, при условии, что по нему есть исполняемость.
>
> $ command -v .bin/chdate
> .bin/chdate
>
> Или если в «$PATH» за каким-то чертом внесен относительный путь, то также 
> именно он и будет возвращен.
>
> $ export PATH=".:$PATH"
> $ cd .bin
> $ command -v chdate
> ./chdate

Да, забавно. Можно и относительные пути писать, ./run-me синтаксис нужен что
бы добавить слеш в путь, тогда PATH не используется.

Из POSIX 2013 по built-in ``command -v``:

  Utilities, regular built-in utilities, command_names including a 
  character, and any implementation-defined functions that are found using the
  PATH variable (as described in Command Search and Execution), **shall** be
  written as **absolute** pathnames.

Но по env var ``PATH``:

  If the pathname being sought contains a , the search through the path
  prefixes shall not be performed. If the pathname begins with a , the
  specified path is resolved.

И тут же:

  The list shall be searched from beginning to end, applying the filename to
  each prefix, until an executable file with the specified name and appropriate
  execution permissions is found.

Выходит что "**shall** be written as **absolute** pathnames" не совсем
однозначно трактуется.
-- 
http://defun.work/

Re: shell background job and trap SIGCHILD

[dimas]

ааа, тоды извиняюсь, недопонял.
а то я на эту фичу в свое время напоролся - привык в баше писать "function
name()", а потом долго не мог понять, почему в бизибоксе не работает, и как
надо оный бизибокс собрать правильно))


2016-303 12:43 Михаил Касаджиков  wrote:
> 29.10.2016 10:51, dimas пишет:
> > 2016-302 00:34 Михаил Касаджиков  wrote:
> >> Проверил по другому, таки да, на function() dash не реагирует
> > function - башизм, правильнее объявлять функции через "name()"
> >
> Я же написал не «function name()», а просто «function()». Прочитайте всё
> обсуждение — речь идёт об «on_sigchld()» и «print_msg()».
> 

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

29.10.2016 10:51, dimas пишет:
> 2016-302 00:34 Михаил Касаджиков  wrote:
>> Проверил по другому, таки да, на function() dash не реагирует
> function - башизм, правильнее объявлять функции через "name()"
>
Я же написал не «function name()», а просто «function()». Прочитайте всё 
обсуждение — речь идёт об «on_sigchld()» и «print_msg()».

Re: shell background job and trap SIGCHILD

[dimas]

о чем спор? в баше есть команда builtin, которая железно запустит нам
билт-ин-echo, printf, etc


2016-303 01:00 Dmitry Alexandrov <321...@gmail.com> wrote:
> > Проще command -v ${command}
> 
> Пардон, для чего проще?  Для программной проверки, быть может, и так, но для
> восприятия человеком (как здесь) — боюсь, что нет.
> 
> > оно если с полным путем, то бинарь на диске,
> 
> Да не обязательно с полным.  Если подать на вход относительный, то он его и
> вернет, при условии, что по нему есть исполняемость.
> 
> $ command -v .bin/chdate
> .bin/chdate
> 
> Или если в «$PATH» за каким-то чертом внесен относительный путь, то также
> именно он и будет возвращен.
> 
> $ export PATH=".:$PATH"
> $ cd .bin
> $ command -v chdate
> ./chdate
> 
> > если нет - то builtin.
> 
> Или функция, или элемент синтаксиса языка (как «if», например).

Re: shell background job and trap SIGCHILD

[dimas]

2016-302 00:34 Михаил Касаджиков  wrote:
> Проверил по другому, таки да, на function() dash не реагирует

function - башизм, правильнее объявлять функции через "name()"

Re: shell background job and trap SIGCHILD

[Dmitry Alexandrov]

> Dmitry Alexandrov <321...@gmail.com> wrote:
>> >> Можно заменить на print (этот
>> >> обязан быть builtin'ом) и посмотреть, будет ли разница.
>> > Не будет :)
>> > % bash -c 'which printf'
>> > /usr/bin/printf
>> > % dash -c 'which printf'
>> > /usr/bin/printf
>
>> ??$ which which?? еще прикажите.
>
>> А так и в ГНУ Баше, и в Дебиановом Аше встроенный printf, разумеется, есть.
>
>> $ bash -c 'type printf'
>> printf is a shell builtin
>> $ dash -c 'type printf'
>> printf is a shell builtin
>
> Проще command -v ${command}

Пардон, для чего проще?  Для программной проверки, быть может, и так, но для 
восприятия человеком (как здесь) — боюсь, что нет.

> оно если с полным путем, то бинарь на диске,

Да не обязательно с полным.  Если подать на вход относительный, то он его и 
вернет, при условии, что по нему есть исполняемость.

$ command -v .bin/chdate
.bin/chdate

Или если в «$PATH» за каким-то чертом внесен относительный путь, то также 
именно он и будет возвращен.

$ export PATH=".:$PATH"
$ cd .bin
$ command -v chdate
./chdate

> если нет - то builtin.

Или функция, или элемент синтаксиса языка (как «if», например).

Re: shell background job and trap SIGCHILD

[Andrey Melnikoff]

Dmitry Alexandrov <321...@gmail.com> wrote:
> >> Можно заменить на print (этот
> >> обязан быть builtin'ом) и посмотреть, будет ли разница.
> > Не будет :)
> > % bash -c 'which printf'
> > /usr/bin/printf
> > % dash -c 'which printf'
> > /usr/bin/printf

> ??$ which which?? еще прикажите.

> А так и в ГНУ Баше, и в Дебиановом Аше встроенный printf, разумеется, есть.

> $ bash -c 'type printf'
> printf is a shell builtin
> $ dash -c 'type printf'
> printf is a shell builtin

Проще command -v ${command} - оно если с полным путем, то бинарь на диске,
если нет - то builtin.

Re: shell background job and trap SIGCHILD

[Andrey Melnikoff]

Artem Chuprina  wrote:
> Михаил Касаджиков -> Andrey Nikitin  @ Fri, 28 Oct 2016 13:17:38 +0300:

[...]

> Моя вот практика показывает, что если хочется работать с любым юниксом и
> нормально управлять процессами, то оптимальный выбор - perl. В линуксах
Поздно, он уже протух тот перл ;)

Сейчас - стильно-модно-молодежно кросплатформенно писать на питоне. Особенно
радует, когда для сборки пакаджа тянеться питон с обвязкой из-за скриптика
заменяемого на вызов 
"printf "#define BUILDTIME %s" $(date --date='2016-09-12 00:00:00' +'%s') > 
include/buildtime.h".

Re: shell background job and trap SIGCHILD

[Dmitry Alexandrov]

>> Можно заменить на print (этот
>> обязан быть builtin'ом) и посмотреть, будет ли разница.
> Не будет :)
> % bash -c 'which printf'
> /usr/bin/printf
> % dash -c 'which printf'
> /usr/bin/printf

«$ which which» еще прикажите.

А так и в ГНУ Баше, и в Дебиановом Аше встроенный printf, разумеется, есть.

$ bash -c 'type printf'
printf is a shell builtin
$ dash -c 'type printf'
printf is a shell builtin

Re: shell background job and trap SIGCHILD

[Igor]

On 10/28/16 18:51, Tim Sattarov wrote:

On 28/10/16 11:22 AM, Igor wrote:

On 10/28/16 18:20, Tim Sattarov wrote:

On 28/10/16 06:17 AM, Михаил Касаджиков wrote:


Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на
сервере может оказаться нечто совсем обрезанное. Или же указывай
явно «#!/bin/ksh», «#!/bin/bash», «#!/bin/zsh» и т.д.


Вот кстати, наткнулся я пару раз на такой подход и понял что
универсальным методом, возможно, должен быть #!/usr/bin/env bash, etc.
Потому как может он лежать где угодно. Особенно на Маках, где то brew,
то macports,  то ещё что то .
Этот подход не без проблем конечно, но лучше, чем зашитый путь к
бинарю...


А что если и env лежит не в стандартном пути? Или на маках он всегда в
/usr/bin/env?


Он всегда и почти во всех системах находится по этому пути, потому что
это очень простая команда :)

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

Re: shell background job and trap SIGCHILD

[Tim Sattarov]

On 28/10/16 11:22 AM, Igor wrote:
> On 10/28/16 18:20, Tim Sattarov wrote:
>> On 28/10/16 06:17 AM, Михаил Касаджиков wrote:
>>>
>>> Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на
>>> сервере может оказаться нечто совсем обрезанное. Или же указывай
>>> явно «#!/bin/ksh», «#!/bin/bash», «#!/bin/zsh» и т.д.
>>>
>> Вот кстати, наткнулся я пару раз на такой подход и понял что
>> универсальным методом, возможно, должен быть #!/usr/bin/env bash, etc.
>> Потому как может он лежать где угодно. Особенно на Маках, где то brew,
>> то macports,  то ещё что то .
>> Этот подход не без проблем конечно, но лучше, чем зашитый путь к
>> бинарю...
>>
> А что если и env лежит не в стандартном пути? Или на маках он всегда в
> /usr/bin/env?
>
Он всегда и почти во всех системах находится по этому пути, потому что
это очень простая команда :)

Re: shell background job and trap SIGCHILD

[Tim Sattarov]

On 28/10/16 06:17 AM, Михаил Касаджиков wrote:
>
> Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на сервере 
> может оказаться нечто совсем обрезанное. Или же указывай явно «#!/bin/ksh», 
> «#!/bin/bash», «#!/bin/zsh» и т.д.
>
Вот кстати, наткнулся я пару раз на такой подход и понял что
универсальным методом, возможно, должен быть #!/usr/bin/env bash, etc.
Потому как может он лежать где угодно. Особенно на Маках, где то brew,
то macports,  то ещё что то .
Этот подход не без проблем конечно, но лучше, чем зашитый путь к бинарю...

Re: shell background job and trap SIGCHILD

[Igor]

On 10/28/16 18:20, Tim Sattarov wrote:

On 28/10/16 06:17 AM, Михаил Касаджиков wrote:


Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на сервере может 
оказаться нечто совсем обрезанное. Или же указывай явно «#!/bin/ksh», 
«#!/bin/bash», «#!/bin/zsh» и т.д.


Вот кстати, наткнулся я пару раз на такой подход и понял что
универсальным методом, возможно, должен быть #!/usr/bin/env bash, etc.
Потому как может он лежать где угодно. Особенно на Маках, где то brew,
то macports,  то ещё что то .
Этот подход не без проблем конечно, но лучше, чем зашитый путь к бинарю...

А что если и env лежит не в стандартном пути? Или на маках он всегда в 
/usr/bin/env?

Re: shell background job and trap SIGCHILD

[Victor Wagner]

On Fri, 28 Oct 2016 11:20:07 -0400
Tim Sattarov  wrote:

> On 28/10/16 06:17 AM, Михаил Касаджиков wrote:
> >
> > Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на
> > сервере может оказаться нечто совсем обрезанное. Или же указывай
> > явно «#!/bin/ksh», «#!/bin/bash», «#!/bin/zsh» и т.д. 
> Вот кстати, наткнулся я пару раз на такой подход и понял что
> универсальным методом, возможно, должен быть #!/usr/bin/env bash, etc.
> Потому как может он лежать где угодно. Особенно на Маках, где то brew,
> то macports,  то ещё что то .
> Этот подход не без проблем конечно, но лучше, чем зашитый путь к
> бинарю...

Где-то мне попадался дистрибутив Linux, где env лежал в /bin...
Хотя в 6-м редхате, например есть симлинк из /usr/bin/env в /bin/env

Re: shell background job and trap SIGCHILD

[Eugene Berdnikov]

On Fri, Oct 28, 2016 at 04:37:09PM +0300, Artem Chuprina wrote:
> Моя вот практика показывает, что если хочется работать с любым юниксом и
> нормально управлять процессами, то оптимальный выбор - perl.
...
> Правда, библиотечку приходится написать и таскать с собой, потому что на

 +1

 Однако ж, с управлением процессами под перлом мне как-то раз удалось
 словить приключения. :) Был демон на перле, который для логгинга юзал
 сторонний модуль Sys::Syslog. И вот однажды, после наката апдейтов,
 в этом модуле случилось зацикливание. Оказалось, что добрые дяди,
 писавшие этот модуль, в один прекрасный день решили, что писать в сислог
 по умолчанию нужно в... подпроцессе! Ну и сделали в своём модуле fork().
 А когда рождённый в либе подпроцесс завершался, демон получал SIGCHLD,
 переходил к очистке структур для потомка и удивлялся тому, что такого
 pid'a в регистре нет. Конечно же, ситуация с "посторонним" сигналом
 у меня добросовестно обрабатывалась записью мессаджа в сислог... :))
 Модуль логгинга был заменён самописным.

 Если же хочется добротного шелла, то zsh можно найти собранный
 практически для любых юниксов.
-- 
 Eugene Berdnikov

Re: shell background job and trap SIGCHILD

[Artem Chuprina]

Михаил Касаджиков -> Andrey Nikitin  @ Fri, 28 Oct 2016 13:17:38 +0300:

 >>> Если шелл в скрипте работает не так, как
 >>> интерактивный, то смысл его как шелла практически пропадает. Лучше
 >>> писать скрипты на совсем другом языке, чем на _чуть-чуть_ не таком.
 >> В "яблочко", хотя и грустно это (
 >>
 > Ну, когда работаешь с зоопарком платформ, всё равно будешь интерактивно
 > работать в чём-то одном, а писать под весь зоопарк и не максимально используя
 > функциональность интерпретатора, а минимально. Тут или шашечки, или ехать.

 > Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на сервере 
 > может
 > оказаться нечто совсем обрезанное. Или же указывай явно «#!/bin/ksh»,
 > «#!/bin/bash», «#!/bin/zsh» и т.д.

Моя вот практика показывает, что если хочется работать с любым юниксом и
нормально управлять процессами, то оптимальный выбор - perl. В линуксах
и FreeBSD он в норме есть, и на любом юниксе легкодоступен. При этом
базовые функции работы с процессами везде работают одинаково, а если
что-то может не поддерживаться, то об этом в документации написано, и
можно этим не пользоваться.

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

Я даже делал подобные скрипты, которые передаются в stdin команде ssh
host perl. Для операций на хосте с read-only файловой системой.

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

28.10.2016 13:09, Andrey Nikitin пишет:
> В Fri, 28 Oct 2016 12:31:35 +0300
> Artem Chuprina  пишет:
>
>> Если шелл в скрипте работает не так, как
>> интерактивный, то смысл его как шелла практически пропадает. Лучше
>> писать скрипты на совсем другом языке, чем на _чуть-чуть_ не таком.
> В "яблочко", хотя и грустно это (
>
Ну, когда работаешь с зоопарком платформ, всё равно будешь интерактивно 
работать в чём-то одном, а писать под весь зоопарк и не максимально используя 
функциональность интерпретатора, а минимально. Тут или шашечки, или ехать.

Тут если используешь «#!/bin/sh», то, будь добр, учитывай что на сервере может 
оказаться нечто совсем обрезанное. Или же указывай явно «#!/bin/ksh», 
«#!/bin/bash», «#!/bin/zsh» и т.д.

Re: shell background job and trap SIGCHILD

[Andrey Nikitin]

В Fri, 28 Oct 2016 12:31:35 +0300
Artem Chuprina  пишет:

> Если шелл в скрипте работает не так, как
> интерактивный, то смысл его как шелла практически пропадает. Лучше
> писать скрипты на совсем другом языке, чем на _чуть-чуть_ не таком.

В "яблочко", хотя и грустно это (

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

28.10.2016 12:39, Илья пишет:
> В Fri, 28 Oct 2016 11:40:34 +0300
> Alexander Galanin  пишет:
>
>> В Debian давно по умолчанию продвигается dash. 
> 1)на малинке 
> $lsb_release -d ; echo $SHELL
> Description:  Raspbian GNU/Linux 8.0 (jessie)
> /bin/bash
>
> 2)на ноуте
> $ lsb_release -d ; echo $SHELL
> Description:  Debian GNU/Linux 8.6 (jessie)
> /bin/bash
>
> Как то странно продвигают. Установлено все по дефолту.
>
Вообще-то:

$ readlink -f $(which sh)
/bin/dash

А то что в качестве интерактивной оболочки — bash — не новость.

В RHEL в качестве /bin/sh используется bash. Вот это — неприятно.

Re: shell background job and trap SIGCHILD

[Илья]

В Fri, 28 Oct 2016 11:40:34 +0300
Alexander Galanin  пишет:

> В Debian давно по умолчанию продвигается dash. 

1)на малинке 
$lsb_release -d ; echo $SHELL
Description:Raspbian GNU/Linux 8.0 (jessie)
/bin/bash

2)на ноуте
$ lsb_release -d ; echo $SHELL
Description:Debian GNU/Linux 8.6 (jessie)
/bin/bash

Как то странно продвигают. Установлено все по дефолту.

Re: shell background job and trap SIGCHILD

[Artem Chuprina]

Alexander Galanin -> debian-russian@lists.debian.org  @ Fri, 28 Oct 2016 
11:40:34 +0300:

 >> Ну так bash вроде по умолчанию во многих дистрибутивах. 
 >> Или я ошибаюсь? И что в этом плохого? 

 > В Debian давно по умолчанию продвигается dash. 

В качестве /bin/sh. В качестве интерактивного шелла он по современным
стандартам не годится.

При этом, увы, забывают, что ключевое свойство sh - скриптуется то, что
выполняется руками. Если шелл в скрипте работает не так, как
интерактивный, то смысл его как шелла практически пропадает. Лучше
писать скрипты на совсем другом языке, чем на _чуть-чуть_ не таком.

 > А чем плох bash, сказано прямо в bash(1):
 > BUGS
 >It's too big and too slow.
 > и далее.

 > -- 
 > Alexander Galanin

Re: shell background job and trap SIGCHILD

[Artem Chuprina]

Илья -> debian-russian@lists.debian.org  @ Fri, 28 Oct 2016 10:18:38 +0300:

 >> А zsh и ksh молодцы, но, увы, не модные среди масс
 >> для которых shell и bash одно и то же ))

 > Ну так bash вроде по умолчанию во многих дистрибутивах. 
 > Или я ошибаюсь? И что в этом плохого? 

Это как с Windows. Самым распространенным оказывается самое плохое
решение из приемлемых.

 > Возможно, по причине отсутствия неких стандартов для
 > обработки таких ситуаций и родили systemd.

Нет, systemd родили по причине отсутствия стандартов для обработки
других ситуаций. И даже не стандартов, а общепринятой практики.

Но с systemd даже нельзя сказать, что самое плохое из
приемлемых. Во-первых, неприемлемое, а во-вторых, единственое. Ту
задачу, которую заявляет (но по моим представлениям о понятии "решать",
не решает) комплект systemd/logind, пока больше никто не решает.

Все средства есть, но применены только в systemd. Через жопу, но больше
никто.

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

28.10.2016 09:41, Andrey Nikitin пишет:
> В Fri, 28 Oct 2016 00:34:42 +0300
> Михаил Касаджиков  пишет:
>
>> Так что, ksh реагирует на «(…) &», а dash ещё и на внешние программы. Bash — 
>> пофигист.
> Фишка в том, что ни bash ни dash не реагируют на _завершение_ «(…) &»,
> только на запуск, см. отметки времени в первом письме.

Не, запуск «(…) &» им тоже пофиг. Просто по времени оно так выглядит потому что 
сразу за «(…) &» у нас идёт print_msg(), в начале которого «date» — внешняя 
программа. Вот на её завершение и реагирует.

А на завершение «(…) &» реагирует только ksh, и то, после завершение работы 
sleep. Кстати, sleep встроен только в ksh.

Скрипт:

$ cat test_child1.sh
#!/bin/ksh

print_msg()
{
   echo "`date +%H:%M:%S`: $@"
}

on_sigchld() {
   trap '' CHLD
   print_msg "SIGCHLD $!"
   trap on_sigchld CHLD
}

trap on_sigchld CHLD

date

(
   print_msg "child started"
   sleep 2
date
   print_msg "child exited after 2 sec"
) &
CPID=$!
sleep 1
print_msg "parent $$, child $CPID"

sleep 4
print_msg "bye..."

Для ksh:

$ ./test_child1.sh
Пт окт 28 11:48:40 MSK 2016
11:48:*40*: child started
11:48:*41*: parent 12989, child 12991
Пт окт 28 11:48:42 MSK 2016
11:48:42: child exited after 2 sec
11:48:*45*: SIGCHLD 12991
11:48:45: bye...

Для dash:

$ ./test_child1.sh
Пт окт 28 11:46:08 MSK 2016
11:46:08: SIGCHLD← это после date
11:46:*08*: child started
11:46:09: SIGCHLD 11285← это после sleep 1
11:46:09: parent 11282, child 11285
11:46:09: SIGCHLD 11285← это после date в print_msg()
Пт окт 28 11:46:10 MSK 2016
11:46:10: child exited after 2 sec
11:46:*13*: SIGCHLD 11285← это после sleep 4
11:46:13: bye...
11:46:13: SIGCHLD 11285← это после date в print_msg()


> А zsh и ksh молодцы, но, увы, не модные среди масс
> для которых shell и bash одно и то же ))

Я ksh только в скриптах всякого ентерпрайза встречаю. потому что на всяких 
HP-UX именно оно.

Re: shell background job and trap SIGCHILD

[Alexander Galanin]

On Fri, 28 Oct 2016 10:18:38 +0300
Илья  wrote:

> Ну так bash вроде по умолчанию во многих дистрибутивах. 
> Или я ошибаюсь? И что в этом плохого? 

В Debian давно по умолчанию продвигается dash. 

А чем плох bash, сказано прямо в bash(1):
BUGS
   It's too big and too slow.
и далее.

-- 
Alexander Galanin

Re: shell background job and trap SIGCHILD

[Илья]

В Fri, 28 Oct 2016 09:41:37 +0300
Andrey Nikitin  пишет:
 
> А zsh и ksh молодцы, но, увы, не модные среди масс
> для которых shell и bash одно и то же ))

Ну так bash вроде по умолчанию во многих дистрибутивах. 
Или я ошибаюсь? И что в этом плохого? 

Возможно, по причине отсутствия неких стандартов для
обработки таких ситуаций и родили systemd.

Re: shell background job and trap SIGCHILD

[Andrey Nikitin]

В Fri, 28 Oct 2016 00:34:42 +0300
Михаил Касаджиков  пишет:

> Так что, ksh реагирует на «(…) &», а dash ещё и на внешние программы. Bash — 
> пофигист.

Фишка в том, что ни bash ни dash не реагируют на _завершение_ «(…) &»,
только на запуск, см. отметки времени в первом письме.

А zsh и ksh молодцы, но, увы, не модные среди масс
для которых shell и bash одно и то же ))

Re: shell background job and trap SIGCHILD

[Andrey Nikitin]

В Thu, 27 Oct 2016 23:56:21 +0300
Artem Chuprina  пишет:

> Можно заменить на print (этот
> обязан быть builtin'ом) и посмотреть, будет ли разница.
Не будет :)
% bash -c 'which printf'
/usr/bin/printf
% dash -c 'which printf'
/usr/bin/printf

> Я не исключу, что это вопрос не к "как обрабатывается", а к "как
> запускается". Хотя, конечно, интеллект на тему "в реальном обработчике
> SIGCHLD отфильтровать завершившиеся PID'ы по списку именно бэкграундных
> задач" в продвинутых шеллах вполне возможен.

В обработчике SIGCHLD нет простого способа узнать какой процесс рипнулся,
в теории можно через `jobs -l`, но на практике работает везде по разному,
проще заменить shell на др. язык.

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

27.10.2016 23:56, Artem Chuprina пишет:
> Михаил Касаджиков -> Andrey Nikitin  @ Thu, 27 Oct 2016 22:59:51 +0300:
>
>  >>> Есть подозрение что dash и bash имеют баг в обработке команды trap arg 
> SIGCHLD.
>  >>>
>  >>> Есть некий шелл скрипт (код в конце письма), который (imho) должен 
> работать так,
>  >>> как он работает только в ZSH.
>  >>> А именно, обработчик SIGCHLD должен быть вызван _сразу_ после завершения 
> фонового процесса.
>  >>>
>  >>> % zsh ./bg.sh 
>  >>> 13:02:08: parent 32128, child 32131
>  >>> 13:02:10: child exited after 2 sec
>  >>> 13:02:10: SIGCHLD 32131
>  >>> 13:02:12: bye...
>  >>>
>  >>> Bash-у вообще на..ть на установленный обработчик SIGCHLD
>  >>> % bash ./bg.sh  
>  >>> 13:03:06: parent 32149, child 32150
>  >>> 13:03:08: child exited after 2 sec
>  >>> 13:03:10: bye...
>  >>>
>  >>> Ну а "родной" /bin/sh он же Dash лучше бы и не делал ничего.
>  >>> % dash ./bg.sh
>  >>> 13:03:49: parent 32157, child 32158
>  >>> 13:03:49: SIGCHLD 32158
>  >>> 13:03:51: child exited after 2 sec
>  >>> 13:03:53: SIGCHLD 32158
>  >>> 13:03:53: bye...
>  >>> 13:03:53: SIGCHLD 32158
>  >>>
>  >>> WTF?
>  >>>
>  >>> [code]
>  >>> print_msg()
>  >>> {
>  >>>echo "`date +%H:%M:%S`: $@"
>  >>> }
>  >>>
>  >>> on_sigchld() {
>  >>>trap '' CHLD
>  >>>print_msg "SIGCHLD $!"
>  >>>trap on_sigchld CHLD
>  >>> }
>  >>>
>  >>> trap on_sigchld CHLD
>  >>>
>  >>> (
>  >>>sleep 2
>  >>>print_msg "child exited after 2 sec"
>  >>> ) &
>  >>>
>  >>> print_msg "parent $$, child $!"
>  >>>
>  >>> sleep 4
>  >>> print_msg "bye..."
>  >>> [/code]
>  >>>
>  >> Dash отрабатывает правильно — у него нет встроенной реализации sleep и для
>  >> этого он вызывает внешнюю программу — её SIGCHILD мы и ловим.
>  >>
>  >> Ksh тоже работает как и ожидается.
>  >>
>  >> А вот bash это дело игнорирует.
>  >>
>  >>
>  > Всё ещё веселее.
>
>  > Dash реагирует как на вызов внешних программ, так и на вызовы 
> пользовательских
>  > функций «print_msg()». И это не считая дочерние процессы «(…) &».
>
> В print_msg вызывается echo. Кто сказал, что оно сегодня builtin? У
> классического sh - нет, внешняя программа. Можно заменить на print (этот
> обязан быть builtin'ом) и посмотреть, будет ли разница.

У ksh93, dash и bash — buildin. И man {k,da,ba}sh со мной согласен.

>  > Ksh реагирует на дочерние процессы «(…) &». Пользовательские функции и 
> внешние программы он игнорирует.
>
>  > Документация, к сожалению, явно не указывает как именно это дело должно 
> обрабатываться.
>
> Я не исключу, что это вопрос не к "как обрабатывается", а к "как
> запускается". Хотя, конечно, интеллект на тему "в реальном обработчике
> SIGCHLD отфильтровать завершившиеся PID'ы по списку именно бэкграундных
> задач" в продвинутых шеллах вполне возможен.

В процессах видны дочерние {k,da,ba}sh и sleep.


Проверил по другому, таки да, на function() dash не реагирует, CHLD срабатывал 
именно на date.

Так что, ksh реагирует на «(…) &», а dash ещё и на внешние программы. Bash — 
пофигист.

Re: shell background job and trap SIGCHILD

[Artem Chuprina]

Михаил Касаджиков -> Andrey Nikitin  @ Thu, 27 Oct 2016 22:59:51 +0300:

 >>> Есть подозрение что dash и bash имеют баг в обработке команды trap arg 
 >>> SIGCHLD.
 >>>
 >>> Есть некий шелл скрипт (код в конце письма), который (imho) должен 
 >>> работать так,
 >>> как он работает только в ZSH.
 >>> А именно, обработчик SIGCHLD должен быть вызван _сразу_ после завершения 
 >>> фонового процесса.
 >>>
 >>> % zsh ./bg.sh 
 >>> 13:02:08: parent 32128, child 32131
 >>> 13:02:10: child exited after 2 sec
 >>> 13:02:10: SIGCHLD 32131
 >>> 13:02:12: bye...
 >>>
 >>> Bash-у вообще на..ть на установленный обработчик SIGCHLD
 >>> % bash ./bg.sh  
 >>> 13:03:06: parent 32149, child 32150
 >>> 13:03:08: child exited after 2 sec
 >>> 13:03:10: bye...
 >>>
 >>> Ну а "родной" /bin/sh он же Dash лучше бы и не делал ничего.
 >>> % dash ./bg.sh
 >>> 13:03:49: parent 32157, child 32158
 >>> 13:03:49: SIGCHLD 32158
 >>> 13:03:51: child exited after 2 sec
 >>> 13:03:53: SIGCHLD 32158
 >>> 13:03:53: bye...
 >>> 13:03:53: SIGCHLD 32158
 >>>
 >>> WTF?
 >>>
 >>> [code]
 >>> print_msg()
 >>> {
 >>>echo "`date +%H:%M:%S`: $@"
 >>> }
 >>>
 >>> on_sigchld() {
 >>>trap '' CHLD
 >>>print_msg "SIGCHLD $!"
 >>>trap on_sigchld CHLD
 >>> }
 >>>
 >>> trap on_sigchld CHLD
 >>>
 >>> (
 >>>sleep 2
 >>>print_msg "child exited after 2 sec"
 >>> ) &
 >>>
 >>> print_msg "parent $$, child $!"
 >>>
 >>> sleep 4
 >>> print_msg "bye..."
 >>> [/code]
 >>>
 >> Dash отрабатывает правильно — у него нет встроенной реализации sleep и для
 >> этого он вызывает внешнюю программу — её SIGCHILD мы и ловим.
 >>
 >> Ksh тоже работает как и ожидается.
 >>
 >> А вот bash это дело игнорирует.
 >>
 >>
 > Всё ещё веселее.

 > Dash реагирует как на вызов внешних программ, так и на вызовы 
 > пользовательских
 > функций «print_msg()». И это не считая дочерние процессы «(…) &».

В print_msg вызывается echo. Кто сказал, что оно сегодня builtin? У
классического sh - нет, внешняя программа. Можно заменить на print (этот
обязан быть builtin'ом) и посмотреть, будет ли разница.

 > Ksh реагирует на дочерние процессы «(…) &». Пользовательские функции и 
 > внешние программы он игнорирует.

 > Документация, к сожалению, явно не указывает как именно это дело должно 
 > обрабатываться.

Я не исключу, что это вопрос не к "как обрабатывается", а к "как
запускается". Хотя, конечно, интеллект на тему "в реальном обработчике
SIGCHLD отфильтровать завершившиеся PID'ы по списку именно бэкграундных
задач" в продвинутых шеллах вполне возможен.

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

27.10.2016 22:32, Михаил Касаджиков пишет:
> 27.10.2016 13:20, Andrey Nikitin пишет:
>> Привет.
>>
>> Есть подозрение что dash и bash имеют баг в обработке команды trap arg 
>> SIGCHLD.
>>
>> Есть некий шелл скрипт (код в конце письма), который (imho) должен работать 
>> так,
>> как он работает только в ZSH.
>> А именно, обработчик SIGCHLD должен быть вызван _сразу_ после завершения 
>> фонового процесса.
>>
>> % zsh ./bg.sh 
>> 13:02:08: parent 32128, child 32131
>> 13:02:10: child exited after 2 sec
>> 13:02:10: SIGCHLD 32131
>> 13:02:12: bye...
>>
>> Bash-у вообще на..ть на установленный обработчик SIGCHLD
>> % bash ./bg.sh  
>> 13:03:06: parent 32149, child 32150
>> 13:03:08: child exited after 2 sec
>> 13:03:10: bye...
>>
>> Ну а "родной" /bin/sh он же Dash лучше бы и не делал ничего.
>> % dash ./bg.sh
>> 13:03:49: parent 32157, child 32158
>> 13:03:49: SIGCHLD 32158
>> 13:03:51: child exited after 2 sec
>> 13:03:53: SIGCHLD 32158
>> 13:03:53: bye...
>> 13:03:53: SIGCHLD 32158
>>
>> WTF?
>>
>> [code]
>> print_msg()
>> {
>>echo "`date +%H:%M:%S`: $@"
>> }
>>
>> on_sigchld() {
>>trap '' CHLD
>>print_msg "SIGCHLD $!"
>>trap on_sigchld CHLD
>> }
>>
>> trap on_sigchld CHLD
>>
>> (
>>sleep 2
>>print_msg "child exited after 2 sec"
>> ) &
>>
>> print_msg "parent $$, child $!"
>>
>> sleep 4
>> print_msg "bye..."
>> [/code]
>>
> Dash отрабатывает правильно — у него нет встроенной реализации sleep и для 
> этого он вызывает внешнюю программу — её SIGCHILD  мы и ловим.
>
> Ksh тоже работает как и ожидается.
>
> А вот bash это дело игнорирует.
>
>
Всё ещё веселее.

Dash реагирует как на вызов внешних программ, так и на вызовы пользовательских 
функций «print_msg()». И это не считая дочерние процессы «(…) &».

Ksh реагирует на дочерние процессы «(…) &». Пользовательские функции и внешние 
программы он игнорирует.

Документация, к сожалению, явно не указывает как именно это дело должно 
обрабатываться.

Re: shell background job and trap SIGCHILD

[Михаил Касаджиков]

27.10.2016 13:20, Andrey Nikitin пишет:
> Привет.
>
> Есть подозрение что dash и bash имеют баг в обработке команды trap arg 
> SIGCHLD.
>
> Есть некий шелл скрипт (код в конце письма), который (imho) должен работать 
> так,
> как он работает только в ZSH.
> А именно, обработчик SIGCHLD должен быть вызван _сразу_ после завершения 
> фонового процесса.
>
> % zsh ./bg.sh 
> 13:02:08: parent 32128, child 32131
> 13:02:10: child exited after 2 sec
> 13:02:10: SIGCHLD 32131
> 13:02:12: bye...
>
> Bash-у вообще на..ть на установленный обработчик SIGCHLD
> % bash ./bg.sh  
> 13:03:06: parent 32149, child 32150
> 13:03:08: child exited after 2 sec
> 13:03:10: bye...
>
> Ну а "родной" /bin/sh он же Dash лучше бы и не делал ничего.
> % dash ./bg.sh
> 13:03:49: parent 32157, child 32158
> 13:03:49: SIGCHLD 32158
> 13:03:51: child exited after 2 sec
> 13:03:53: SIGCHLD 32158
> 13:03:53: bye...
> 13:03:53: SIGCHLD 32158
>
> WTF?
>
> [code]
> print_msg()
> {
>echo "`date +%H:%M:%S`: $@"
> }
>
> on_sigchld() {
>trap '' CHLD
>print_msg "SIGCHLD $!"
>trap on_sigchld CHLD
> }
>
> trap on_sigchld CHLD
>
> (
>sleep 2
>print_msg "child exited after 2 sec"
> ) &
>
> print_msg "parent $$, child $!"
>
> sleep 4
> print_msg "bye..."
> [/code]
>
Dash отрабатывает правильно — у него нет встроенной реализации sleep и для 
этого он вызывает внешнюю программу — её SIGCHILD  мы и ловим.

Ksh тоже работает как и ожидается.

А вот bash это дело игнорирует.

shell background job and trap SIGCHILD

[Andrey Nikitin]

Привет.

Есть подозрение что dash и bash имеют баг в обработке команды trap arg SIGCHLD.

Есть некий шелл скрипт (код в конце письма), который (imho) должен работать так,
как он работает только в ZSH.
А именно, обработчик SIGCHLD должен быть вызван _сразу_ после завершения 
фонового процесса.

% zsh ./bg.sh 
13:02:08: parent 32128, child 32131
13:02:10: child exited after 2 sec
13:02:10: SIGCHLD 32131
13:02:12: bye...

Bash-у вообще на..ть на установленный обработчик SIGCHLD
% bash ./bg.sh  
13:03:06: parent 32149, child 32150
13:03:08: child exited after 2 sec
13:03:10: bye...

Ну а "родной" /bin/sh он же Dash лучше бы и не делал ничего.
% dash ./bg.sh
13:03:49: parent 32157, child 32158
13:03:49: SIGCHLD 32158
13:03:51: child exited after 2 sec
13:03:53: SIGCHLD 32158
13:03:53: bye...
13:03:53: SIGCHLD 32158

WTF?

[code]
print_msg()
{
   echo "`date +%H:%M:%S`: $@"
}

on_sigchld() {
   trap '' CHLD
   print_msg "SIGCHLD $!"
   trap on_sigchld CHLD
}

trap on_sigchld CHLD

(
   sleep 2
   print_msg "child exited after 2 sec"
) &

print_msg "parent $$, child $!"

sleep 4
print_msg "bye..."
[/code]