Re: shell background job and trap SIGCHILD
> 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
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
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
>> Можно заменить на 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
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
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
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
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
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
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
Михаил Касаджиков -> 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點
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&ExpertNewsId=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
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
В 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
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
Илья -> 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
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.