Есть скрипт-диспетчер, который обрабатывает передаваемые ему параметры и в зависимости от них запускает ту или иную процедуру. В запускаемую процедуру он передает какие-то параметры, когда процедура отработает (она должна возвращатькод возврата и желательно какую-то текстовую информацию), пишет в журнал результат выполнения этой процедуры.
Подскажите, как это должно осуществляться?
Сейчас у меня такой скелет для диспетчера (в $rsub имя скрипта-обработчика):



Не пойму, что должно быть в скрипте-обработчике.
Если в нем выполняется exit, то завершается и скрипт-диспетчер (в консоль выводится только ***1).
Если exit не указан, то после отработки обработчика управление возвращается к диспетчеру, но тогда непонятно, как получить код возврата.
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

С возвратом вроде бы определился.
Если последней строкой в обработчике указать анонимный хэш (в котором будут указаны и код возврата, и текст), в диспетчере его можно получить в $ret.
А как в обработчик передать аргументы?

А как обычно подобная архитектура (диспетчер + обработчики во внешних файлах) реализуется?

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



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

Да, через глобальные переменные работает.
В диспетчере задаю $::ARG = { ... }, в обработчике выполняю my $ARG = $::ARG, затем в диспетчере обнуляю $::ARG = undef.
Можно ожидать непредвиденные осложнения?

WarstoneПосмотрите как делается перезагрузка модулей и загрузка модулей в ран тайме.
Очевидно для этого структура модуля должна соответствовать определенным правилам.
Внешний же скрипт (хорошо, не внешний, эвалируемый) никакими обременениями в плане структуры не отягощен. Его вообще можно делать полностью автономным, вся разница будет в том, что в одном случае аргументы будут передаваться в @ARGV, в другом в $::ARG.

Nick121И вообще-то это не вызов внешнего скрипта.
Напрасно я не обратил на это внимание.
Скрипт эвалируется внутри глобального адресного пространства текущего скрипта.
И соответственно, в нем нельзя подключать модули, объявлять процедуры которые бы конфликтовали с модулями/процедурами скрипта-диспетчера.

С одной стороны есть некоторое удобство — в диспетчере можно написать общие процедуры и из обработчиков просто обращаться к ним.
Но с другой, я полагал что у такого подхода преимуществом будет автономность скриптов-обработчиков (которые полноценно будут работать как при запуске из диспетчера, так и при самостоятельном запуске), а получается, этого преимущества нет и тогда уж лучше использовать pm-модули.

Ни IPC::Run, ни вызов второго экземпляра perl я использовать не хочу.
Во-первых, дело происходит в Windows, а там накладные расходы на запуск процессов и на IPC выше, чем в *nix. Запускаться же диспетчер может часто (это обработчик SMS-шлюза), причем он не в бесконечном цикле опрашивает шлюз, а шлюз при поступлении SMS запускает диспетчер, передавая ему необходимые данные.
Во-вторых, это костыли, если уж делать правильно, то с подключаемыми модулями, используя plugin-архитектуру.
Просто я с Perl знаком плохо и в нем не смогу это сделать правильно.