Re: shell background job and trap SIGCHILD

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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 файловой системой.

一週大市總結 (24-28/10) - 結算日失23000點 恒指10月跌343點

2016-10-28 Пенетрантность Metro Radio 
If you cannot read this e-mail, please visit:
http://lnk.ie/1K23Y/e=debian-russian@lists.debian.org/http://www.metroradio.com.hk/Campaign/104/Weekly_Report/20161028.html

metroradio.com.hk一週大市總結
24-28/10/2016

大市總結

28/10　星期五
恒指收報：22954 (-177)   全日成交：683億
結算日失23000點 恒指10月跌343點
港股連跌4日，且失守23000點，創兩個月低位。今日為期指結算日，淡友成功挾好倉，恒指低開低走，午後跌穿23000點，低試22848點，收報22954點...

27/10　星期四
恒指收報：23132 (-193)   全日成交：587億
恒指三連跌 半新股浩得再瀉12%

26/10　星期三
恒指收報：23325 (-239)   全日成交：521億
港股低走、賭股逆市行運 長汽績差跌11%

25/10　星期二
恒指收報：23565 (-39)全日成交：554億
港股全日悶局 吉利又創新高

24/10　星期五
恒指收報：23604 (+229)   全日成交：740億
港股企穩50天線 內銀股功不可沒

詳情：http://www.metroradio.com.hk/MetroFinance/News/NewExpertDetail.aspx?ExpertId=6d46ce17-38b5-418f-836d-1deb09d974e9=cb596f6b-9fe5-47cf-98f3-659aac86ead9

Copyright 2016(c) Metro Broadcast Corporation Limited. All rights reserved.

Note: 
This email is in Traditional Chinese Font with UTF-8 format. If it does not 
display properly, please follow the steps below: 
1. Click "View" of the menu bar of your e-mail tool. 
2. Select "Unicode (UTF-8)" from the "Encoding" section of the drop-down menu.
請勿回覆此電郵，如欲停止接收《一週大市總結》，請到https://member.metroradio.com.hk/UpdateUserSubscribe.aspx。閣下之要求將於3個工作天內生效。

Re: shell background job and trap SIGCHILD

2016-10-28 Пенетрантность Михаил Касаджиков 
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

2016-10-28 Пенетрантность Andrey Nikitin 
В Fri, 28 Oct 2016 12:31:35 +0300
Artem Chuprina  пишет:

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

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

Re: shell background job and trap SIGCHILD

2016-10-28 Пенетрантность Михаил Касаджиков 
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

2016-10-28 Пенетрантность Илья 
В 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность Михаил Касаджиков 
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

2016-10-28 Пенетрантность 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

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

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

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

Re: shell background job and trap SIGCHILD

2016-10-28 Пенетрантность 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

2016-10-28 Пенетрантность 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 на др. язык.