Можно указать произвольный таймаут, по истечении которого ожидание прерывается.
Также можно заставить скрипт принудительно завершить родительский и дочерние процессы, которые не завершились сами к моменту наступления таймаута.
Скрипт пришлось родить для запуска баз по именам с помощью стартера платформы 1С 8.3.
Известная проблема состоит в том, что стартер (1cestart.exe) завершается раньше запущенного им дочернего процесса, что делает использование команды Start бессмысленым. Данный скрипт опрашивает список процессов по идентификатору родительского процесса PID средствами WMI с указанным интервалом, и завершается, когда ссылок на PID не остается.
Теперь можно забыть о прописывании версий и прочих индивидуальных настроек баз в скрипты, а указывать только файл списка баз (или сослаться на него из 1cv82common1CESCmn.cfg) и имя базы — все остальное стартер найдет в списке баз.
Область применения — пакетный запуск конфигуратора (тестирование, архивация, выгрузка/загрузка исходников для трехстороннего сравнения и прочей обработки).
Разумеется, применение этого скрипта не ограничивается запуском 1С, единственное ограничение — дочерние процессы 2 и следующих уровней не просматриваюся. Допилить на этот случай не сложно, но это приведет к дополнительным запросам к WMI (количество уровней вложенности дерева процессов + 1), что приведет к дополнительным расходам ресурсов и повышению вероятности взятия в оборот недочерних процессов с совпадающими идентификаторами.
Запуск нужно производить при помощи «cscript //nologo …», чтобы избежать появления диалоговых окон.
Версия 1.0.4, 2024-06-02.
Добавлен контроль времени создания дочерних процессов.
Вероятность попадания процессов с идентичным PID родителя в список ожидания завершения сведена почти к нулю (почти — потому что в некоторых случаях не удается точно определить время запуска и/или завершения корневого процесса).
может пригодится комуhttp://amatashkin.com/2012/03/16/backup-1c-database-on-schedule/
(1) kuzyara, ога! Сам по тому скрипту настраивал архивирование, дополнив его сбросом сделанного архива на ftp(бухгалтеры просили для аудиторов такое устроить). Думаю, Powershell гораздо гибче и удобнее в таких вопросах
(2) GreenDragon, Согласен, гибче и удобнее — если не считать размера интерпретатора и настройку инфраструктуры, чтобы оно вообще могло выполняться. В корпоративной полностью настроенной сети, когда вся автоматизация писана на PS, это выгодно, но не для точечного применения с многократной загрузкой интерпретатора из CMD-скриптов.
WSH многократно легче и совместим с любыми версиями Windows, актуальными на текущий момент. Да и данная конкретная задача таких мощностей не требует…
не удалось запустить приложение код ошибки 8 (win 8.1)
(4) iov, Под W8 не тестировал, только под W7/Srv2008.
Попробуй запустить с повышенными привилегиями («Запуск от имени администратора») а также простую командную строку cmd.exe без параметров — вроде была такая ошибка при несуществующей рабочей папке (/W), либо проблема в самой командной строке.
Какие параметры передавал скрипту?
(3)
Это ты о чём вообще?
И зачем в принципе cmd, когда всё прекрасно пишется на PS?
Актуальными на данный момент можно считать только операционки, выпущенные после WinXP. Все они работают с PS (Хотя и WinXP тоже поддерживает PS)
(6) GreenDragon, О времени запуска первого скрипта для начала — PS раскочегаривается медленнее жабы. Но это как раз мелочи.
А вот скажи, ты все скрипты свои подписываешь или демократию у себя в сети развел?
Инструмент действительно мощный, и чтобы ваять вредоносный код на нем семи пядей во лбу быть не надо…
Билли (или кто там теперь рулит) не зря по умолчанию поставил политику restricted.
У CMD своя ниша, у PS — своя. Там, где нужно подряд запустить несколько программ с почти статическими параметрами, раскочегаривать PS нет никакого смысла. Причем ниша последнего сильно наступает на владения компилируемых языков, и приблуды сложнее выложенного здесь скрипта я бы предпочел делать с использованием полноценного отладчика. Того гляди GUI на нем писать начнут, как на питоне и подобных…
CMD безусловно убогий и кривой, зато простой и быстрый. Замечательно, что MS родил наконец что-то не такое глючное и сравнимое по возможностям с интерпретаторами под Linux 30-летней выдержки (и даже слегка перестарался :)), но срочно переползать на него и переписывать имеющееся хозяйство нет никакого желания. Они бы начали делать его лет 15 назад вместе с ядром NT 🙁
Была бы у меня своя сеть я бы тоже озаботился доменными политиками, раздачей сертификатов и скриптами на PS, или лучше приличной библиотекой в бинариках, безо всяких прокладок-интерпретаторов.
Только вместо этого у меня в хозяйстве мелкие сервера, которые толком никто не админит, и покрупнее, админам которых не сильно озабочены стройностью инфраструктуры, когда за оптимизацию никто не платит, заморачиваться не хотят.
В такой ситуации вполне устраивают менее требовательные вещи, хоть и отладчика приличного (бесплатного) не найти, разве только ECMAScript + Eclipse…
Впрочем, это все демагогия и споры о вкусах.
Что я выложил, то выложил, не вижу смысла далее полемику разводить.
Спасибо, достойный и развёрнутый ответ.
Для больших сетей и периодически решаемых в них задач, прекрасно подходит PS. В твоём конкретном случае с маленькой сетью, действительно нет особой нужды заморачиваться. Про скорость… Ну, я тут не разруливаю скриптами посадки/взлёты самолётов или отправление поездов с атомной станции, так что задержка запуска на пару-тройку секунд не является критичным параметром для выбора среды.
Политики… По этому поводу можно заглянутьсюда . Батники, кстати, вполне себе успешно могут тоже дел наворотить, так что с точки зрения безопасности PS скрипты более контролируемы.
Для меня батники имеют только один плюс — большая часть эникейщиков сможет после меня разобраться и модифицировать его.
В общем, ок. Благодарю за уделённое на ответы время и приятный диалог!
(8) GreenDragon, Взаимно.
И спасибо за ссылку — сделать скрипт для групповой подписи других скриптов интересная идея.
Реализация для дочерних процессов 2го уровня не планируется?
(10) Spoke37, Увы, только за отдельную плату.