научите пользоваться командой wait

[Ленивая Бестолочь]

мана у меня на нее нет почемуто :-/

все, что нашел полезного - в ABS, однако там или не все, или я обламываюсь.

ситуация такая:
мне нужно оптимизировать один скрипт.
в числе прочего там есть момент, когда он подключается к оралковому серверу с помощью sqlplus и запрашивает оттуда большой объем данных.
я хочу делать это в несколько потоков. последовательно получается - запросы запускаются по очереди, потом склеиваю результат cat-ом, все ок.
попробовал параллельно. по всей видимости скрипт завершается раньше, чем дочерние процессы, что нельзя, т.к. склевание произойдет раньше, чем закончатся запросы, к тому же, вроде как такие процессы станут зомби.
понял, что придется как-то дождаться завершения процессов.
у wait есть праметр - номер процесса.
мне это не подходит, т.к. процессов много, не wait-ить же все...
еще у него в качестве параметра можно (согласно ABS) написать вот такое: wait %?S, где S - часть команды, которую нужно ждать.
но такой вариант тоже не работает (я не знаю, почему - наверное ждет только один процесс).

нет ли у wait какого-нибудь ключа типа - ждать завернешия всех дочерних процессов?
или, может быть есть другой способ?

[alfss]

в гугле
Мютексы
Симофоры
Потоки

[broom]

в гугле
Мютексы
Симофоры
Потоки

Да, и всё это в Shell'е...

[t.t]

мана у меня на нее нет почемуто :-/

Потому что это внутренняя команда. См. help wait или man bash / info bash.

нет ли у wait какого-нибудь ключа типа - ждать завернешия всех дочерних процессов?
или, может быть есть другой способ?

А jobs не поможет?

If -x is given, COMMAND is run after all job specifications that appear in ARGS have been replaced with the process ID of that job's process group leader.

[Goodvin]

в гугле
Мютексы
Симофоры
Потоки

Вам на www.gramota.ru, милейший.
Чтобы не позориться с "симофорами" и не путать людей своими "советами".

Прежде чем посылать кого-либо в гугль, надо самому туда сходить и проверить то, что советуете.

[Ленивая Бестолочь]

Потому что это внутренняя команда

в смысле - внутренняя команда баша?
у меня на man wait открывается описание системной функции wait.

А jobs не поможет?

похоже, что поможет - буду пробовать.
спасибо большое.

[t.t]

Потому что это внутренняя команда

в смысле - внутренняя команда баша?

Вообще говоря, почти любого shell-а.

спасибо большое.

Не за что. Рад помочь.

[broom]

Потому что это внутренняя команда

в смысле - внутренняя команда баша?

А если man 1 wait? У меня открывается мануал к bashу, и в конце там есть

wait [n ...]
Wait for each specified process and return its termination status. Each n may be a process ID or a job specification; if a job
spec is given, all processes in that job’s pipeline are waited for. If n is not given, all currently active child processes
are waited for, and the return status is zero. If n specifies a non-existent process or job, the return status is 127. Other-
wise, the return status is the exit status of the last process or job waited for.

[Ленивая Бестолочь]

с jobs разобрался, да, можно с помощью него сделать.

manager3-r:/home/rakul# man 1 wait
No manual entry for wait in section 1

If n is not given, all currently active child processes
are waited for, and the return status is zero

If n is not given, all currently active child processes
are waited for, and the return status is zero.

тоесть просто - wait мне подойдет, получается? :-)


проверил - подойдет :-)
извиняюсь - както нелепо тему развел из-за ерунды :-)
ну - зато научился.

[t.t]

Потому что это внутренняя команда

в смысле - внутренняя команда баша?

А если man 1 wait? У меня открывается мануал к bashу

От дистрибутива зависит. Подозреваю, что в арче есть симлинк вроде /usr/share/man/man1/wait.1.gz -> bash.1.gz

[rm_]

извиняюсь - както нелепо тему развел из-за ерунды :-)
ну - зато научился.

И всеобщее внимание обратили на этот wait, что тоже полезно.
Я, к примеру, сейчас соптимизировал свой бэкап-скрипт. Он у меня основан на использовании программы mirrordir, которая обходит каталоги, и найденные различия копирует из основной копии в бэкап. Как оказалось, если запускать все бэкапы параллельно, они завершаются быстрее, чем если каждый пускать по очереди. Получилось примерно так:

Код: Выделить всё

mount /backup
mirrordir /source/dir1 /backup/dir1 &
mirrordir /source/dir2 /backup/dir2 &
mirrordir /source/dir3 /backup/dir3 &
mirrordir /source/dir4 /backup/dir4 &
wait
umount /backup