Софт из говна, торфа, палок и костылей
Когда-то давно были эпические срачи на тему "монолитный софт" (условно говоря - скопировали exe-шник и все работает) vs хардкорные софтины из тысяч мелких файлов, ставящихся куда попало.
Надо заметить, что в винде нету пакетного менеджера и нет общепринятого места, где лежат grep, awk, комманд-интерпретатор умеет гораздо меньше чем баш и вообще "все плохо". Поэтому когда в голову начинает вещать червь и хочется не писать программу, а обойтись "одной строкой на баше" - это все вырождается в кошмарные конструкции на бат-файлах, gnuwin32, кульных прожках вроде nncronlite и Bitvise Tunnelier, с прописыванием всех путей ко всему в отдельных файлах параметров и прочем кошмаре.
Вот я сейчас ради развлечения таки завел на винде обновление rrd по крону, генерацию графиков и закачивание их на веб-сервер, дабы жена могла втыкать на графики атмосферного давления и температуры на веб-морде.
Адъ кромешный, надо заметить. Количество всяких мелочей, различных компов, составных частей системы и прочего настолько большое, что реально когда что-нибудь идет не так, можно двинутся башкой отлаживать. Пределом была введенная русская буква C в путям к командам в файле cron.tab от nncronlite, из-за чего оно не работало. Причем отладить это можно только ожиданием пока расписание сработает - в лучшем случае раз в минуту.
Если бы это все было одним исполняемым файлом, все было намного проще.
Надо заметить, что в винде нету пакетного менеджера и нет общепринятого места, где лежат grep, awk, комманд-интерпретатор умеет гораздо меньше чем баш и вообще "все плохо". Поэтому когда в голову начинает вещать червь и хочется не писать программу, а обойтись "одной строкой на баше" - это все вырождается в кошмарные конструкции на бат-файлах, gnuwin32, кульных прожках вроде nncronlite и Bitvise Tunnelier, с прописыванием всех путей ко всему в отдельных файлах параметров и прочем кошмаре.
Вот я сейчас ради развлечения таки завел на винде обновление rrd по крону, генерацию графиков и закачивание их на веб-сервер, дабы жена могла втыкать на графики атмосферного давления и температуры на веб-морде.
Адъ кромешный, надо заметить. Количество всяких мелочей, различных компов, составных частей системы и прочего настолько большое, что реально когда что-нибудь идет не так, можно двинутся башкой отлаживать. Пределом была введенная русская буква C в путям к командам в файле cron.tab от nncronlite, из-за чего оно не работало. Причем отладить это можно только ожиданием пока расписание сработает - в лучшем случае раз в минуту.
Если бы это все было одним исполняемым файлом, все было намного проще.
Windows Scripting Host - наш выбор
(Anonymous) 2011-01-17 08:11 am (UTC)(link)Re: Windows Scripting Host - наш выбор
Re: Windows Scripting Host - наш выбор
Re: Windows Scripting Host - наш выбор
Ещё там есть конкретная дока по поводу того, как создать объект WSH с подробным описанием передового метода «echo» (и кучей примеров к нему).
(Посмотрел) О! В последние 2 года в той доке ещё появилось описание пары объектов, которые могу подключить сетевой диск, сделать шоткат на рабочем столе и запусить любую программу!
Это всё, конечно, охренеть как круто — но почему-то обычные административные работы в винде у меня не ограничиваются созданием сетевых шар и шоткатов на рабочих столах. Более того, как раз это я могу и в .bat-файле сделать.
К сожалению, по всем остальным возможностям WSH в msdn лежыт не дока, а обрывочные сведения.
Re: Windows Scripting Host - наш выбор
http://msdn.microsoft.com/en-us/library/9bbdkx3k.aspx
+ в сети куча инфы типа вот такого вот
http://www.computerperformance.co.uk/Logon/WSH_Simple.htm
я не знаю есть ли в сети библия вида "делаем шоугодно на WScript", но мамой клянусь - любая практическая задача вида "как создать пользователя на WScript" ищется гуглом в пол-пинка.
Огромное преимущество WScript перед bat-файлами - это наличие человеческого языка программирования (я имею в виду JScript, про VBScript рекомендую забыть сразу) c возможностью человеческой отладки через Visual Studio (хотя были по-моему и решения для отладки полегковеснее, не интересовался их судьбой).
Ещё один плюс - это то что из WBScript доступны COM-обьекты которые поддерживают IDispath (а таких большинство). Т.е. практически все задачки вида "Поднять Excel, создать файл и впихнуть туда отчёт" делаются за вменяемое время.
Re: Windows Scripting Host - наш выбор
О, как клёво! Её-то я и не приметил (видел только Reference). (Кстати, топ-раздел там замечателен. msdn такой msdn).
В отличие от Reference добавлены примеры работы с COM и WMI. (Кстати, опять о качестве msdn). Ссылка на описание WMI, впрочем, посылает в MSDN, в котором что-то сегодня bigle не ищет (хи-хи) -- но то, что я помню, было не меньшым феерическим уродством (детально описывалось как создать объект WMI и какие у него есть абстрактные методы для подключения абстрактных управляющих объектов. Как реально виндой порулить -- т.е. там отстрелить лишний процэсс или проверить текущее состояние элемента policy, который ты глазами видишь -- это оставлялось поискать для самостоятельной тренировки).
То есть, в msdn -- не дока, а говно. WScript -- это вообще ничто, я OLE, WMI, exec и echo могу и из tcl и из clisp дёрнуть, притом я мог это и безо всякого базворда «WScript».
Короткий итог: КГ/АМ.