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 это дело игнорирует.

Re: Shell

[Ivan Shmakov]

 Artem Chuprina r...@ran.pp.ru writes:
 Ivan Shmakov - debian-russian@lists.debian.org @ Wed, 04 Jul 2012

 IS • ${varn#PATTERN} (${varn##PATTERN}) — значение переменной varn,
 IS за исключением наименьшей (наибольшей) /ведущей/ подстроки,
 IS удовлетворяющей шаблону PATTERN; в частности, d=${f##*/}
 IS равносильно d=$(dirname $f);

 AC basename

Именно.

Реализовать этими подстановками dirname(1) существенно сложнее.

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86obnubqyu@gray.siamics.net

Re: Shell

[Artem Chuprina]

Ivan Shmakov - debian-russian@lists.debian.org  @ Wed, 04 Jul 2012 11:13:46 
+0700:

 IS• ${varn#PATTERN} (${varn##PATTERN}) — значение переменной varn,
 IS   за исключением наименьшей (наибольшей) /ведущей/ подстроки,
 IS   удовлетворяющей шаблону PATTERN; в частности, d=${f##*/}
 IS   равносильно d=$(dirname $f);

basename


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq8bzr02@wizzle.ran.pp.ru

Re: Shell, Perl

[Артём Н.]

03.07.2012 08:23, Ivan Shmakov пишет:
   И да, как мне кажется, я все же научился писать читаемый код на
   Perl.  Изучив Scheme.
Перспективно... :-)

  АН Так причём тут проверка в конфиге?  Достаточно проверки в
  АН загрузчике конфига:
 
  AH config:
 
  АН OPT_PARAM1=123
 
  АН Скрипт:
 
  АН . config
  АН OPT_PARAM1=${ENV_USER_PARAM1-:OPT_PARAM1}
 
  AC Можно.  Но обычно удобнее в конфиге написать
 
  AC OPT_PARAM1=${OPT_PARAM1:-value1}
 
  AC и позволить пользователю переопределять именно OPT_PARAM_1,
  AC использование которой он потом увидит, а не неочевидно с нею связанную
  AC ENV_USER_PARAM1
 
   BTW, есть и более короткий вариант:
 
 : ${VARN:=VALUE}
Тоже вариант. Просто я все подстановки не помню.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff34032.3080...@yandex.ru

Re: shell programming

[Stanislav Maslovski]

On 29/07/2009, Konstantinow Andrey lllxa3ap...@gmail.com wrote:
 подскажите, пожалуйста, сам не разобрался, как можно указать, что
 данную комманду необходимо выполнить от лица определенного VT? мне вот
 надо разукрасить по разному терминалы от 1 до 6.

Если под разукрасить имелось ввиду послать определенные
esc-последовательности драйверу терминала, то как обычно, с помощью
перенаправления в/в:

echo -ne \033 /dev/$tty

 кстати, где и как
 увеличить кол-во этих терминалов?

/etc/inittab

 вторая часть вопроса: как определить, в на какой консоли я сейчас
 нахожусь?

tty

-- 
BR,
Stanislav

Re: shell programming

[Konstantinow Andrey]

спасибо за ответ!

нет, имелось в виду выполнение setterm на другой консоли.

On Wed, Jul 29, 2009 at 01:34:24PM +0400, Stanislav Maslovski wrote:
 On 29/07/2009, Konstantinow Andrey lllxa3ap...@gmail.com wrote:
  подскажите, пожалуйста, сам не разобрался, как можно указать, что
  данную комманду необходимо выполнить от лица определенного VT? мне вот
  надо разукрасить по разному терминалы от 1 до 6.
 
 Если под разукрасить имелось ввиду послать определенные
 esc-последовательности драйверу терминала, то как обычно, с помощью
 перенаправления в/в:
 
 echo -ne \033 /dev/$tty
 
  кстати, где и как
  увеличить кол-во этих терминалов?
 
 /etc/inittab
 
  вторая часть вопроса: как определить, в на какой консоли я сейчас
  нахожусь?
 
 tty
 
 -- 
 BR,
 Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell programming

[Иван Лох]

On Wed, Jul 29, 2009 at 06:32:40AM +0300, Konstantinow Andrey wrote:
 On Wed, Jul 29, 2009 at 02:04:34AM +0400, Иван Лох wrote:
  Команду нельзя выполнить от лица VT.
 
 ну вот если я пишу нечто в rc.local, оно выполняется на первой
 консоли. как выполнить команду на других консолях?

Это нечто имеет стандартное устройство ввода, стандартное устройство
вывода и стандартное устройство печати ошибок. Это могут быть
разные устройства. Вы можете перенаправить стандартное устройство 
вывода обычным образом 

   надо разукрасить по разному терминалы от 1 до 6. кстати, где и как
  
  PS1=\l
  
 что это значит? я вообще во всем этом не разбираюсь, не посоветуете ли
 ман, где можно прочитать про такие элементарные вещи? 

PS1 Это переменная окружения изменяющая приглашение командной оболочки.
\l позволяет вывести номер терминала.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell programming

[Stanislav Maslovski]

On Wed, 2009-07-29 at 13:29 +0300, Konstantinow Andrey wrote:
 спасибо за ответ!
 
 нет, имелось в виду выполнение setterm на другой консоли.

setterm -term linux -background red whatever else you need /dev/$tty

Re: shell programming

[Konstantinow Andrey]

спасибо, не думал, что так просто.

On Wed, Jul 29, 2009 at 12:02:45PM +0100, Stanislav Maslovski wrote:
 On Wed, 2009-07-29 at 13:29 +0300, Konstantinow Andrey wrote:
  спасибо за ответ!
  
  нет, имелось в виду выполнение setterm на другой консоли.
 
 setterm -term linux -background red whatever else you need /dev/$tty
 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell programming

[Dmitri Samsonov]

Konstantinow Andrey пишет:
 где и как
 увеличить кол-во этих терминалов?

  /etc/inittab

--
 Dmitri Samsonov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell programming

[Иван Лох]

On Tue, Jul 28, 2009 at 11:13:07PM +0300, Konstantinow Andrey wrote:
 Здравтсвуйте!
 
 подскажите, пожалуйста, сам не разобрался, как можно указать, что
 данную комманду необходимо выполнить от лица определенного VT? мне вот

Команду нельзя выполнить от лица VT.

 надо разукрасить по разному терминалы от 1 до 6. кстати, где и как

PS1=\l



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell programming

[Konstantinow Andrey]

On Wed, Jul 29, 2009 at 02:04:34AM +0400, Иван Лох wrote:
 On Tue, Jul 28, 2009 at 11:13:07PM +0300, Konstantinow Andrey wrote:
  Здравтсвуйте!
  
  подскажите, пожалуйста, сам не разобрался, как можно указать, что
  данную комманду необходимо выполнить от лица определенного VT? мне вот
 
 Команду нельзя выполнить от лица VT.

ну вот если я пишу нечто в rc.local, оно выполняется на первой
консоли. как выполнить команду на других консолях?
 
  надо разукрасить по разному терминалы от 1 до 6. кстати, где и как
 
 PS1=\l
 
что это значит? я вообще во всем этом не разбираюсь, не посоветуете ли
ман, где можно прочитать про такие элементарные вещи? 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell programming

[Mishustin Alexey]

7/29/2009, Konstantinow Andrey lllxa3ap...@gmail.com вы писали:

  надо разукрасить по разному терминалы от 1 до 6. кстати, где и как

 PS1=\l

что это значит? я вообще во всем этом не разбираюсь, не посоветуете ли
ман, где можно прочитать про такие элементарные вещи?

man bash (или какой у вас shell)

С уважением,
Алексей Мишустин


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: shell question

[Oleg Verych]

25-01-2007, Alexander GQ Gerasiov пишет:
 Хеллоу.

 Кто-нить скажите мне, как правильно написать на шелле следующую вещь:

 #!/bin/sh

/bin/bash 3.X

set -o pipefail

 cmd1 | cmd2
 if cmd1 закончилось с ошибкой;then
 exit 1
 else
 exit 0
 fi


Ещё идеи?

 Только очень не хочется для этого файлы создавать. Можно еще из
 сабшелла SIG_USR1 послать, но тоже как-то кажется слишком громоздким =\

p.s. resend, fsck

--
-o--=O`C
 #oo'L O
___=E M


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell question

[Oleg Verych]

25-01-2007, Dmitry E. Oboukhov пишет:
 #!/bin/sh
[]

 { cmd1 || error=1 }|cmd2

 if test $error = 1; then ...

Имеется в виду, если трубка порвалась. То что она не туда вставилась
тут не надо, мне кажется.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell - help wanted

[Victor Wagner]

On 2005.10.31 at 17:16:22 +0200, Dmitrii Varvashenia wrote:

 Доброго времени суток, russian
 
 Сейчас у меня возникла интересная задача:
 Нужно с нескольких серверов собирать список файлов на ftp и передавать их 
 на один из них. Сейчас задачу решил по своему (см. конец письма) и понял, 
 что всё ужастно тормозит.

Это -естественно. У тебя же там поднимается новый процесс ls на каждый
файл.

Можно попробовать find с ключиком  -ls. Только поле для сортировки нужно
будет правильно указывать.

 Собираюсь всё это впихивать в mysql, дабы облегчить жизнь серверу, который 
 занимается работой с получившимися файлами и разными выборками.
 
 Собственно вопрос: может кто подскажет тул, который одинаково отрабатывает 
 на woody и sarge в области вывода списка файлов с намёком сформировать 
 список для втыкания всего этого в mysql? (у ls не совпадает количество 
 столбцов и формат даты разный - хотя у меня есть смутное подозрение, что 
 ядро здесь имеет первостепенное значение)

Напрасное подозрение. Уж скорее имеет значение текущая локаль. И если
считать дату за один столбец, то количество столбцов вполне совпадает.

У ls из coreutils 5.2.1 (sarge) есть ключик --time-style, который
позволяет привести вывод к тому же виду, что и у ls из fileutls 4.1
(--time-style locale). К сожалению,ls из fileutils 4.1 такого не
понимает.


А вообще я бы рекомендовал отказаться для решения этой задачи от shell и
использовать более другой скриптовый язык, который не требует порождения
отдельного процесса для того, чтобы узнать содержимое inode, т.е.
имеющий встроенную команду для доступа к системному вызов stat.

Например, perl (у которого есть stat и модуль File::Find) или tcl
(у которого есть file state и glob или for_recursive_glob в Tclx)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell - help wanted

[Artem Chuprina]

Dmitrii Varvashenia - debian-russian@lists.debian.org  @ Mon, 31 Oct 2005 
17:16:22 +0200:

 DV Собственно вопрос: может кто подскажет тул, который одинаково
 DV отрабатывает на woody и sarge в области вывода списка файлов с
 DV намёком сформировать список для втыкания всего этого в mysql?

perl

 DV (у ls не совпадает количество столбцов и формат даты разный - хотя
 DV у меня есть смутное подозрение, что ядро здесь имеет первостепенное
 DV значение)

Ядро тут вообще ни с какого боку.

 DV #start
 DV #!/bin/sh
 DV #ftp-cron
 DV find /home/ftp -type f | sort/root/temp.txt
 DV printf ''/home/ftp/server2.txt
 DV while read LOOP
 DV do
 DV   SIZE=`ls -ln $LOOP | awk '{print |$3|$4|$5|$6|$7|$8}'`
 DV   LOOP=`echo $LOOP | awk '{print substr($0,10)}'`
 DV   echo $LOOP$SIZE/home/ftp/server2.txt
 DV done /root/temp.txt
 DV rm /root/temp.txt
 DV chown ftp-cron /home/ftp/server2.txt
 DV chmod u+rw,g-rw,o-rw /home/ftp/server2.txt
 DV gzip -9 -S .gz /home/ftp/server2.txt
 DV #end

 DV PS: find использую потому-что не удалось побороть страсть шелла разделять
 DV значения пробелами
 DV PPS: ногами сильно не пинайте - это мой почти самый первый скрпит ;-)

Вообще если говорить о том же самом на том же самом шелле, то

find /home/ftp -type f -print0 | xargs -0 ls -n | awk 

будет работать куда быстрее.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

А Элберет оксюморон! (c)JB


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell - help wanted

[Dmitrii Varvashenia]

Victor Wagner пишет:

что всё ужастно тормозит.

Это -естественно. У тебя же там поднимается новый процесс ls на каждый
файл.


Это сделано, поскольку я не смог нормально обрабатывать файлы с пробелами в 
цикле - он думает что их тут 2 ато и больше..



Можно попробовать find с ключиком  -ls. Только поле для сортировки нужно
будет правильно указывать.


будем пробовать

список для втыкания всего этого в mysql? (у ls не совпадает количество 
столбцов и формат даты разный - хотя у меня есть смутное подозрение, что 
ядро здесь имеет первостепенное значение)

Напрасное подозрение. Уж скорее имеет значение текущая локаль. И если
считать дату за один столбец, то количество столбцов вполне совпадает.



У ls из coreutils 5.2.1 (sarge) есть ключик --time-style, который
позволяет привести вывод к тому же виду, что и у ls из fileutls 4.1
(--time-style locale). К сожалению,ls из fileutils 4.1 такого не
понимает.


просто у меня 2 sarge на разных ядрах (2.4 и 2.6) - так там ls ведёт себя совсем 
по разному. как себя ведет ls из sarge, который 2.6 меня абсолютно устраивает :)


Буду курить в сторону локали - может удастся подстроить под то, что мне нужно.


А вообще я бы рекомендовал отказаться для решения этой задачи от shell и
использовать более другой скриптовый язык, который не требует порождения
отдельного процесса для того, чтобы узнать содержимое inode, т.е.
имеющий встроенную команду для доступа к системному вызов stat.

Например, perl (у которого есть stat и модуль File::Find) или tcl
(у которого есть file state и glob или for_recursive_glob в Tclx)


спасибочки что придал ускорения в нужную сторону - про perl я совсем забыл. ;-) 
хотя ради спортивного интереса стоит довести шеловскую версию до более-мнее рабочей


--
WBR, Dmitrii
ICQ: 193-74-771
Phone: +375-29-40-LINUX


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell - help wanted - fixed

[Dmitrii Varvashenia]

Artem Chuprina пишет:

Вообще если говорить о том же самом на том же самом шелле, то

find /home/ftp -type f -print0 | xargs -0 ls -n | awk 

будет работать куда быстрее.


спасибо, что направил в нужную сторону мысли

find /dir -type f -printf |%h|%f|%A@|%u|%g|%s|\n out.txt

спасло меня

--
WBR, Dmitrii
ICQ: 193-74-771
Phone: +375-29-40-LINUX


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell translation

[Yuri Kozlov]

On Fri, 09 Apr 2004 12:52:31 +0200
 Sergey V. Spiridonov [EMAIL PROTECTED] wrote:

--
|   shell|
|    |
|  | libc |  |
|  |  --  |  |
|  |  ||  |  |
   |  | kernel |  |
   |  ||  |
   |  --  |
   |  |
   


╡  ?? ??? libc :)
╥?? ?? ╢??? ?  
 :)

╟ ? libc ?   ?? ╨? ? ? ???.
╣? ?? ??? ? ?? - ??? ??  - libc!

Shell *?* ??ibc. ? 

╟ ? ??  ???hell ?

Regards,
Yuri Kozlov

Re: shell script DOS

[Госсен Алексей]

Dmitry Astapov wrote:
Evening, swar0g. 


swar0g [EMAIL PROTECTED] 15:14 23/3/2003 wrote:

 s Если же этот фокус сделать таким образом
 s #!/bin/sh
 s shellscript  shellsctipt

 s то система летит в нирвану и даже через сеть не реагирует. Кстати,
 s скриптик вызывался с привилегиями _простого_ пользователя.
man ulimit
ulimit -a

 s Моя проблема теперь вот в чем. Я не знаю как мне быть дальше. Может
 s это у меня руки кривые и я как то неправильно сконфигурировал систему. 
 s Либо это ошибка в кенеле или баше и все это надо сообщить

 s bugs.debian.org?
см. выше.




спасибо всем за советы.


Алексей

Re: shell script DOS

[Oles Stovbenko]

Greetings...

Monday, March 24, 2003, 15:22:36, Oleg P. Philon [EMAIL PROTECTED] wrote:

 #!/bin/sh
 shellscript  shellsctipt

OPP из foldoc dict fork bomb:
OPP #!/bin/sh
OPP $0  $0 

OPP У меня скрипт систему не убил, но неприятностей наделал.
OPP Загрузка под 100%, остановить форки не удаётся.

killall shellscript
несколько раз и все возвернется на круги своя...

-- 
Regards...

 +--
 | Oles' Stovbenko aka $LY Lord of GloomDaemons
 +--
 | Registered Linux User # : 232886
 | ICQ UIN : 27308195
 | NIC-Handle  : OS11-UANIC

Re: shell script DOS

[Dmitry Astapov]

Evening, swar0g. 

swar0g [EMAIL PROTECTED] 15:14 23/3/2003 wrote:

 s Если же этот фокус сделать таким образом
 s #!/bin/sh
 s shellscript  shellsctipt

 s то система летит в нирвану и даже через сеть не реагирует. Кстати,
 s скриптик вызывался с привилегиями _простого_ пользователя.
man ulimit
ulimit -a

 s Моя проблема теперь вот в чем. Я не знаю как мне быть дальше. Может
 s это у меня руки кривые и я как то неправильно сконфигурировал систему. 
 s Либо это ошибка в кенеле или баше и все это надо сообщить
 s bugs.debian.org?
см. выше.


-- 
Dmitry Astapov //ADEpt   E-mail: [EMAIL PROTECTED]
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498  2B08 7867 4860 F5D7 639D

Re: shell script DOS

[Alexey Ozeritsky]

В письме от 23 Март 2003 17:14 swar0g написал:
 Привет

 Решил на выходных научитя писать bash скрипты, достал инфу, поставил
 рядом с собой пиво и начал. Научиться - то научился, вот встала передо
 мной огромная проблема. Случайно написал скриптик, который напрочь
 вешает мою систему к чертовой бабушке. То есть не скриптик а мелочь
 какая - то: решил проверить, что будет, если заставить скрипт открывать
 себя самого.

 Правильно, bash через некоторое время говорила: to many files opened или
 что - то в этом роде и скриптик прикрывала. Никаких проблем с системой.

 Если же этот фокус сделать таким образом
 #!/bin/sh
 shellscript  shellsctipt


у меня
./shellscript: fork: Resource temporarily unavailable

смотреть надо настройки
/etc/security/limits.conf

 то система летит в нирвану и даже через сеть не реагирует. Кстати,
 скриптик вызывался с привилегиями _простого_ пользователя.

 Моя проблема теперь вот в чем. Я не знаю как мне быть дальше. Может это
 у меня руки кривые и я как то неправильно сконфигурировал систему. Либо
 это ошибка в кенеле или баше и все это надо сообщить bugs.debian.org?

 Вообще то я склоняюсь в сторону теории с кривыми руками. Проверить это
 просто. Скриптик стоит выше. Может кто - нибудь из вас его запустит.
 Если система слетать не будет, то я готовлю рукораспремлятель :-)

 Кстати, у меня стоит woody с 2.4.20 самопальным кернелем (gcc-3.0).


 Алексей

-- 
Alexey Ozeritsky
email1: [EMAIL PROTECTED]
email2: [EMAIL PROTECTED]
web: http://make-install.ifirst.ru | icq: UIN 52034320

Re: shell script DOS

[Oleg P. Philon]

Привет, коллеги.

On Sun, Mar 23, 2003 at 03:14:43PM +0100, swar0g wrote:
 #!/bin/sh
 shellscript  shellsctipt

из foldoc dict fork bomb:
#!/bin/sh
$0  $0 

 то система летит в нирвану и даже через сеть не реагирует. Кстати, 
 скриптик вызывался с привилегиями _простого_ пользователя.

У меня скрипт систему не убил, но неприятностей наделал.
Загрузка под 100%, остановить форки не удаётся.

Полез в файл Packages на sid. Нашёл на эту тему набор патчей
kernel-patch-2.4-grsecurity

Появился повод пересобрать ядро.

 Алексей

Auf Wiederlesenophil aka Д-р Антикоммуний
--
Oleg P. Philon  http://gomelug.agava.ru/articles
Linux Lab, Gomel, Belarus   mailto:[EMAIL PROTECTED]
http://anticommunist.narod.ru   mailto:[EMAIL PROTECTED]

Re: shell script DOS

[Andrey Nekrasov]

Hello Oleg P. Philon,

 из foldoc dict fork bomb:
 #!/bin/sh
 $0  $0 
 
  то система летит в нирвану и даже через сеть не реагирует. Кстати, 
  скриптик вызывался с привилегиями _простого_ пользователя.
 
 У меня скрипт систему не убил, но неприятностей наделал.
 Загрузка под 100%, остановить форки не удаётся.
 
 Полез в файл Packages на sid. Нашёл на эту тему набор патчей
 kernel-patch-2.4-grsecurity
 
 Появился повод пересобрать ядро.

 не поможет.
 
-- 
Any statement is incorrect.

Re: shell script DOS

[Michael Shigorin]

On Sun, Mar 23, 2003 at 03:14:43PM +0100, swar0g wrote:
 вешает мою систему к чертовой бабушке. То есть не скриптик а
 мелочь какая - то: решил проверить, что будет, если заставить
 скрипт открывать себя самого.

google://fork+bomb

-- 
  WBR, Michael Shigorin [EMAIL PROTECTED]
  -- Linux.Kiev http://www.linux.kiev.ua/

Re: shell

[Viktor Vislobokov]

  Может кто знает..
  Как можно с помощью shell изменить строку в файле???
  к примеру есть файл
  ---
  ---
  1
  ---
  ---
  нужно заменить
  ---
  ---
  2
  ---
  ---
  причем 1 встречается однажды во всем файле...


  Ну например:

cat file.txt | sed -e 's/1/2/' /tmp/tmp.tmp
mv /tmp/tmp.tmp file.txt




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell

[Alexander Kotelnikov]

 On Wed, 03 Apr 2002 17:49:43 +0600
 Viktor == Viktor Vislobokov [EMAIL PROTECTED] wrote:
Viktor 
 Может кто знает..
 Как можно с помощью shell изменить строку в файле???
 к примеру есть файл
 ---
 ---
 1
 ---
 ---
 нужно заменить
 ---
 ---
 2
 ---
 ---
 причем 1 встречается однажды во всем файле...
Viktor 
ViktorНу например:
Viktor 
Viktor cat file.txt | sed -e 's/1/2/' /tmp/tmp.tmp
Viktor mv /tmp/tmp.tmp file.txt

sed -e 's/^1$/2/'

-- 
Alexander Kotelnikov
Saint-Petersburg, Russia


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell

[Dmitry A. Fedorov]

On Wed, 3 Apr 2002, Viktor Vislobokov wrote:

 From: Viktor Vislobokov [EMAIL PROTECTED]
 To: \Алексей А. Спицын (Aleksey A. Spitsin)\ [EMAIL PROTECTED]
 
Как можно с помощью shell изменить строку в файле???
 
Ну например:
 
 cat file.txt | sed -e 's/1/2/' /tmp/tmp.tmp
 mv /tmp/tmp.tmp file.txt

file=$1
tmpfile=`mktemp /tmp/${file}.XX`

sed -e 's/1/2/' $file $tmpfile  mv $tmpfile $file

-- 
Eсли уж гайка есть, она должна быть затянута до конца
или выкручена нафиг.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: shell script

[Oleg P. Philon]

Привет, коллеги.

On Fri, Oct 26, 2001 at 03:40:37PM +0400, Anatoly Pugachev wrote:
 On Fri, Oct 26, 2001 at 03:26:26PM +0300, Roman Kovalenko wrote:
 #!/bin/sh
 for msg in *.MSG
   do
 lc=`echo $msg  | tr '[a-z]' '[A-Z]'`
 if [ $lc != $msg ]; then
   mv $msg $lc
 fi
done

На всякий случай ещё один способ переименовать файлы -
воспользоваться перловым скриптом rename из пакета perl:

... $ rename 'use locale;s/(.+)/\L$1/' *.MSG

Этот скрипт сделал Ларри Уолл, когда-то давно был в примерах, а размер
имел 5 строк. В него можно добавить ещё одну строку - use locale;

Auf Wiederlesenophil aka Д-р Антикоммуний
--
Oleg P. Philon  http://gomelug.agava.ru/articles
Linux Lab, Gomel, Belarus   mailto:[EMAIL PROTECTED]
http://anticommunist.narod.ru   mailto:[EMAIL PROTECTED]

Re: shell script

[Vlad Harchev]

On Fri, 26 Oct 2001, Alexey Vyskubov wrote:

  Если все эти ухищрения были только для того чтобы переименовать файлы
  то есть такая программка mmv называется, вот пример ее использования:
  
  $ mmv *.tmp #l1.TMP
 
 Кривая она. Русские буквы так и останутся большими.
 
 Хотел попатчить. Почитал source. Мда: 
   
 
 #define mylower(c) (isupper(c) ? (c)-'A'+'a' : (c))

 ну может с libc автора tolower глючила.. Хотя конечно можно было сделать
#ifdef только для нее..
 
 .
 
 #define STRLEN(s) (sizeof(s) - 1)

 Вполне полезный макрос для строковых литералов - вычисляется в compile time.
 
 .
 
 v = mylower(p[0]) - 'a';

 Вот это единственное что может сформировать образ софтины как кривой и
глючной.

 Лично я бы себя на mmv тоже подсаживать не стал - но только чтобы не быть
непортабельным :)

 Best regards,
  -Vlad

Re: shell script

[Viktor Vislobokov]

 извиняюсь что не совсем в тему.
 есть скрипт:

 == cut ==
 #!/bin/sh
 for msg
   in *.MSG
   do
 mv $msg $msg.tmp
 .. и тд.
 done
 == cut ==

 как в этом скрипте привести имя и расширение файлов к нижнему регистру?

Добавь команду вида

NAME=`echo $i | dd conv=lcase`

Виктор

Re: shell script

[Anatoly Pugachev]

On Fri, Oct 26, 2001 at 03:26:26PM +0300, Roman Kovalenko wrote:
 извиняюсь что не совсем в тему.
 есть скрипт:
 
 == cut ==
что-то типа этого

#!/bin/sh
for msg in *.MSG
  do
lc=`echo $msg  | tr '[a-z]' '[A-Z]'`
if [ $lc != $msg ]; then
mv $msg $lc
fi
   done

Сам не проверял =)

Re: shell script

[Alexey Vyskubov]

 lc=`echo $msg  | tr '[a-z]' '[A-Z]'`

tr [:upper:] [:lower:]

[EMAIL PROTECTED]:~$ echo lLфФ | tr [A-Z] [a-z]
llфФ
[EMAIL PROTECTED]:~$ echo lLфФ | tr [:upper:] [:lower:]
llфф

Почувствуйте разницу.

-- 
Алексей

Re: shell script

[Sergey V. Burchu]

Fri, Oct 26, 2001 at 02:48:33PM +0300, Вы написали:
  lc=`echo $msg  | tr '[a-z]' '[A-Z]'`
 
 tr [:upper:] [:lower:]
 
 [EMAIL PROTECTED]:~$ echo lLфФ | tr [A-Z] [a-z]
 llфФ
 [EMAIL PROTECTED]:~$ echo lLфФ | tr [:upper:] [:lower:]
 llфф
 
 Почувствуйте разницу.

Если все эти ухищрения были только для того чтобы переименовать файлы
то есть такая программка mmv называется, вот пример ее использования:

$ mmv *.tmp #l1.TMP

Буковка l после # означает привести все что оно нашло под * к нижнему 
регистру 

Или так :
$ mmv *.* #2.#1

В этом случае поменяются местами названия и расширения файлов :)

А так читайте man mmv.
-- 
Бурчу Сергей.

Re: shell script

[Alexey Vyskubov]

  tr [:upper:] [:lower:]
[...]
 то есть такая программка mmv называется, вот пример ее использования:
 
 $ mmv *.tmp #l1.TMP
 
 Буковка l после # означает привести все что оно нашло под * к нижнему 
 регистру 

[EMAIL PROTECTED]:~$ sudo apt-get install mmv
[...]
[EMAIL PROTECTED]:~$ touch ФУУ.bar
[EMAIL PROTECTED]:~$ mmv *.bar #l1.bar
[EMAIL PROTECTED]:~$ ls *bar
ФУУ.bar
[EMAIL PROTECTED]:~$ sudo dpkg --purge mmv

 А так читайте man mmv.

Не стоит. Как видно из примера выше, это просто еще одна кривая утилита
для тех, кто не умеет использовать стандартные для *nix средства.

-- 
Алексей

Re: shell script

[Nick Potemkin]

On Fri, Oct 26, 2001 at 05:06:16PM +0400, Sergey V. Burchu wrote:

 Если все эти ухищрения были только для того чтобы переименовать файлы
 то есть такая программка mmv называется, вот пример ее использования:
 
 $ mmv *.tmp #l1.TMP

Чудесное решение... Одна строчка в скрипте пишется гораздо быстрее, чем 
изучается ман по mmv :)) 


-- 
Nick Potemkin
Eniro Rus-M
http://www.eniro-m.ru
::: Yellow Pages Moscow
http://www.yellowpages.ru
phone: +7 (095) 799-55-55
fax:  +7 (095) 799-55-09 

Re: shell script

[Alexey Vyskubov]

 Если все эти ухищрения были только для того чтобы переименовать файлы
 то есть такая программка mmv называется, вот пример ее использования:
 
 $ mmv *.tmp #l1.TMP

Кривая она. Русские буквы так и останутся большими.

Хотел попатчить. Почитал source. Мда:   

#define mylower(c) (isupper(c) ? (c)-'A'+'a' : (c))

.

#define STRLEN(s) (sizeof(s) - 1)

.

v = mylower(p[0]) - 'a';

.

Патчить передумал.

Теперь задумайтесь -- хотите ли вы *такому* доверять свои файлы? Я --
нет. Даже если оно работало бы правильно.

-- 
Алексей

Re: shell script

[Alexey Vyskubov]

 то есть такая программка mmv называется, вот пример ее использования:

Интересно, а куда пропало из списка мое письмо про то, какая она кривая?
Кто-нибудь его получил?

-- 
Алексей

Re: shell script

[Oles' Stovbenko]

On Fri, 26 Oct 2001, Alexey Vyskubov wrote:

  то есть такая программка mmv называется, вот пример ее использования:

 Интересно, а куда пропало из списка мое письмо про то, какая она кривая?
 Кто-нибудь его получил?
Получил.
Такое бывает - пути мыла неисповедимы ;)
Иногда вопрос приходит раньше ответа :))

Regards, /$LY

Re: shell script

[Sergey V. Burchu]

Fri, Oct 26, 2001 at 04:48:18PM +0300, Вы написали:
  то есть такая программка mmv называется, вот пример ее использования:
 
 Интересно, а куда пропало из списка мое письмо про то, какая она кривая?
 Кто-нибудь его получил?

Ага, получил. 
Действительно странная программка, да и старая к тому же. (Copyright (c) 1989 
Vladimir Lanin)

Вот еще:

This package was put together by Michael Meskes [EMAIL PROTECTED],
from sources obtained from USENET.

It is now maintained by Bernd Eckenfels [EMAIL PROTECTED] with some
enhancements (NLS Char Support, glibc compiles) from Bernd and kind
contributions from Hartmut Koptein [EMAIL PROTECTED].


Если хочется, можешь писать мантейнеру о баге :)
Я не хочу да и не умею. 
А вообще я впервые с ней встретился когда где-то в прошлом или позапрошлом
году пытался скомпилировать ядро. 
А так никаких нареканий на ее работу у меня не было, да и не использую я 
русские имена файлов :)
-- 
Бурчу Сергей.

Re: shell script

[Anatoly Pugachev]

On Fri, Oct 26, 2001 at 04:48:18PM +0300, Alexey Vyskubov wrote:
  то есть такая программка mmv называется, вот пример ее использования:
 
 Интересно, а куда пропало из списка мое письмо про то, какая она кривая?
 Кто-нибудь его получил?
da, da, ya prochital =)
-- 
/mator

Re: shell script

[Wartan Hachaturow]

On Fri, Oct 26, 2001 at 04:48:18PM +0300, Alexey Vyskubov wrote:

 Интересно, а куда пропало из списка мое письмо про то, какая она кривая?
 Кто-нибудь его получил?

Я получил оба.

-- 
Regards, Wartan.
echo Your stdio isn't very std. 
-- Larry Wall in Configure from the perl distribution

Re: shell script

[Alexey Vyskubov]

 Если хочется, можешь писать мантейнеру о баге :)

Боюсь, всю программу нужно переписать не очень катит в качестве bug
description...

-- 
Алексей