Comments 68
Powershell — настоящий язык программирования, и он обладает потрясающим свойством — стоит только хоть чуть-чуть задуматься о происхождении магических заклинаний с SO, как тебя в полный рост макают в .net. Вместо того, чтобы думать про админские задачи, обнаруживаешь себя в мире волшебных уродливых классов, интерфейсов и монстросити, которая на тебя смотрит со дна .net.
При том, что есть много админских инструментов, которые уводят в недра языка программирования (тот же питон), только .net с C# обладает настолько ярко выраженной ненавистью к красивому и простому.
Э-э-э, а что такого уродливого в классах .NET?
То же, что и в java.
class ReadFromFile
{
static void Main()
{
string text = System.IO.File.ReadAllText(@"C:\Users\Public\TestFolder\WriteText.txt");
System.Console.WriteLine("Contents of WriteText.txt = {0}", text);
string[] lines = System.IO.File.ReadAllLines(@"C:\Users\Public\TestFolder\WriteLines2.txt");
System.Console.WriteLine("Contents of WriteLines2.txt = ");
foreach (string line in lines)
{
Console.WriteLine("\t" + line);
}
Console.WriteLine("Press any key to exit.");
System.Console.ReadKey();
}
}(рандомный пример из интернетов).
Я считаю, что оно антигуманно. Сравните с эквивалентом на питоне:
with open("WriteText.txt") as f:
print(f.read())
with open("WriteText2.txt") as f:
for line in f.readlines():
print(line)Все вот эти class и static void могли быть придуманы только тем, кому насрать на людей, пишущих скрипты.
Так у вас не эквивалент, вот эквивалент на C#
WriteLine(File.ReadAllText("WriteText.txt"));
foreach (var line in File.ReadAllLines("WriteLines2.txt"))
WriteLine(line);Все вот эти class и static void могли быть придуманы только тем, кому насрать на людей, пишущих скрипты.Ну так они и не обязательны. Можно писать без всего этого.
Конечно, можно без этого. Тем паче, что это C#. А сам powershell ещё более ужасающий.
Begin {
# If we fail, stop the pipe...
$ErrorActionPreference = "Stop"
# Look for the command in PATH
$cmdinfo = $(Get-Command $cmd)
if (!$cmdinfo -or !$cmdinfo.Path) {
throw [System.IO.FileNotFoundException] "Failed to find $cmd..";
}
$fullpath = $cmdinfo.Path
# Use of System.Diagnostics.Process to launch the command and redirect its STDIN/STDOUT
$ProcessInfo = New-Object System.Diagnostics.ProcessStartInfo
$ProcessInfo.FileName = $fullpath
$ProcessInfo.RedirectStandardError = $False
$ProcessInfo.RedirectStandardOutput = $True
$ProcessInfo.RedirectStandardInput = $True
$ProcessInfo.UseShellExecute = $False
$ProcessInfo.CreateNoWindow = $False;
if ($cmdpar) {
$ProcessInfo.Arguments = $cmdpar
}
$Process = New-Object System.Diagnostics.Process
$Process.StartInfo = $ProcessInfo
# Reference to the stream reader and writer for the command's STDOUT / STDIN processing
$StdInStreamWriter = $null;
$StdOutStreamReader = $null;
# Sleep time for polling STDIN. To not slow too much the pipeline processing,
# we take 1ms. We have to avoid stressing the CPU with the polling.
$SleepTime=1;
# Control of input parameters if any
if ($bufferedPipe -gt 8000) { $bufferedPipe = 8000; }
if ($bufferedPipe -lt 0) { $bufferedPipe = 0; }
# Launch the command
$ProcessStarted = $Process.Start()
if ($ProcessStarted) {
$StdInStreamWriter = $Process.StandardInput;
$StdOutStreamReader = $Process.StandardOutput;
$StdInStreamWriter.AutoFlush = $True;
} else {
throw [System.Exception] "Failed to open $cmd..";
}
# We use two FIFO stacks to exchange STDIN and STDOUT stream data between
# the PowerShell pipeline processing in the 'premise-style' context and the
# process we have launched for the command. We will feed them in the
# following two poll subprocesses for STDIN and STDOUT as no async operations
# are allowed in a 'premise-style' context.
$StdOutStack = new-object System.Collections.Queue;
if (!$StdOutStack) {
throw [System.Exception] "Can't get a stack..."
}
$StdInStack = new-object System.Collections.Queue;
if (!$StdInStack) {
throw [System.Exception] "Can't get a stack..."
}
# We create two poll subprocesses to read from STDOUT and write into STDIN
# of the process we have launched for the command. As theses subprocesses
# are started from the 'begin' pipeline part of the function, they can then
# makes STDOUT read that feed the STDOUT stack and STDIN write from the
# STDIN stack. Theses operations are not directly doable into the 'process'
# pipeline part of the function as it is a 'premise-style' context.
#
# STDOUT poll subprocess
#
$OutProc = [powershell]::Create().AddScript({
Param ([parameter(Mandatory=$True)]$args)
$Process = $args[0]
$StdOutStreamReader = $args[1]
$SleepTime = $args[2]
$cmd = $args[3]
$StdOutStack = $args[4]
$debugPipe = $args[5]
while (!$StdOutStreamReader.EndOfStream) {
$msgproc = $StdOutStreamReader.ReadLine()
Write-Output ($cmd+": OUT_S: "+[String]$msgproc)
try {
$syncStdOutStack = [System.Collections.Queue]::Synchronized($StdOutStack);
$syncStdOutStack.Enqueue($msgproc)
} finally {
$syncStdOutStack = $null
}
}
if ($debugPipe) { Write-Output ($cmd+": OUT_S terminated.") }
})
$tmp = $OutProc.AddParameter("args", @($Process, $StdOutStreamReader, $SleepTime, $cmd, $StdOutStack, $debugPipe))
$OutJob = $OutProc.BeginInvoke()
#
# STDIN poll subprocess
#
$InProc = [powershell]::Create().AddScript({
Param ([parameter(Mandatory=$True)]$args)
$Process = $args[0]
$StdInStreamWriter = $args[1]
$SleepTime = $args[2]
$cmd = $args[3]
$StdInStack = $args[4]
$debugPipe = $args[5]
$bufferedPipe = $args[6]
...Из рандомного SO ответа про работу с pipe'ом.
Я по своему опыту знаю, то если какой-то инструмент имеет вырвиглазный синтаксис с самого начала, то и вся остальная работа с ним такая же — через ненависть и боль.
Ну что вам на это сказать? Я не знаю, почему ответ был написан так сложно. Может, автор решал какую-то специфичную задачу, требующую указать нестандартные параметры, передаваемые в CreateProcess. Или — чтобы скрипт можно было запустить внутри другого конвейера(pipe) — вложенные конвейеры в Powershell не поддерживаются. А может, он просто не знал как следует Powershell, потому что Powershell не был его основным рабочим языком.
Потому что в Powershell для того, чтобы просто запустить внешнюю команду (исполняемый файл) и перенаправить его стандартный вывод в конвейер (pipe) не нужно делать вообще ничего: достаточно просто набрать имя файла и нажать Enter.
Конвейер в Powershell отличается тем, что по нему передаются не байты, а объекты. Но вывод внешней команды автоматически преобразуется в последовательность объектов Powershell типа String (реализован как тип System.String в .NET). Можно эту последовательность присвоить переменной Powershell: она будет преобразована в массив String, можно — передать на вход другой команды Powershell — например вот эта связка команд отсортирует вывод внешней команды netstat (это — чисто для примера, практического смысла это не имеет):
Можно для дальнейшей обработки сделать разбор строк и преобразовать их в объекты. Например, эта связка команд преобразует все строки выдачи, показывающие соединение, в объект со свойствами LocalIP, LocalPort, RemoteIP, RemotePort, State (и отбросит все строки, не являющиеся соединениями):
(пояснение:? — это псевдоним команды Where-Object, % — Foreach-Object, мне так писать сподручнее, но незнающего это может сбить с толку).
Да, регулярка выглядит весьма не наглядно (и мне пришлось потратить минут 15 на ее написание и отладку), но после разбора вывода с ее помощью мы получаем объекты, с которыми дальше работать может быть сильно проще, чем с сырыми строками.
Результат этой последовательности можно присвоить переменной (получится массив объектов) или передать дальше по конвейеру для дальнейшей обработки, в том числе — способом, не слишком просто достижимым стандартными командами обработки строк (например, отбросить все объекты локальных соединений, у которых LocalIP=RemoteIP).
Потому что в Powershell для того, чтобы просто запустить внешнюю команду (исполняемый файл) и перенаправить его стандартный вывод в конвейер (pipe) не нужно делать вообще ничего: достаточно просто набрать имя файла и нажать Enter.
Конвейер в Powershell отличается тем, что по нему передаются не байты, а объекты. Но вывод внешней команды автоматически преобразуется в последовательность объектов Powershell типа String (реализован как тип System.String в .NET). Можно эту последовательность присвоить переменной Powershell: она будет преобразована в массив String, можно — передать на вход другой команды Powershell — например вот эта связка команд отсортирует вывод внешней команды netstat (это — чисто для примера, практического смысла это не имеет):
netstat -n -p TCP | Sort-ObjectМожно для дальнейшей обработки сделать разбор строк и преобразовать их в объекты. Например, эта связка команд преобразует все строки выдачи, показывающие соединение, в объект со свойствами LocalIP, LocalPort, RemoteIP, RemotePort, State (и отбросит все строки, не являющиеся соединениями):
netstat -n -p TCP `
| ?{$_ -match '^\s+(.+?)\s+(.+?):(.+?)\s+(.+?):(.+?)\s+([^\s]+?)\s*$'}`
| %{New-Object PSObject -Property @{LocalIP=$matches[2];LocalPort=`
$matches[3]; RemoteIP=$matches[4];RemotePort=$matches[5];State=$matches[6]}}
(пояснение:? — это псевдоним команды Where-Object, % — Foreach-Object, мне так писать сподручнее, но незнающего это может сбить с толку).
Да, регулярка выглядит весьма не наглядно (и мне пришлось потратить минут 15 на ее написание и отладку), но после разбора вывода с ее помощью мы получаем объекты, с которыми дальше работать может быть сильно проще, чем с сырыми строками.
Результат этой последовательности можно присвоить переменной (получится массив объектов) или передать дальше по конвейеру для дальнейшей обработки, в том числе — способом, не слишком просто достижимым стандартными командами обработки строк (например, отбросить все объекты локальных соединений, у которых LocalIP=RemoteIP).
Спасибо, приму на вооружение
вот что меня восхищает в PowerShell, так это обмен не потоком как в архаичных системах, а объектами со всеми их свойствами. Можно и свои свойства и свои объекты динамически заводить.
Может реализация не самая удачная, да и выглядит как обертка над .net, но тем не менее это гигантский шаг вперед со времен дос и юникс
Может реализация не самая удачная, да и выглядит как обертка над .net, но тем не менее это гигантский шаг вперед со времен дос и юникс
Даже если это и выглядит как плюс это скорее минус. В обычных архаичных системах вам ничто не мешает кидаться json-ом (например). При этом вы на любом этапе можете вклиниться в поток данных сохранить его в файл, или прочитать из файла, или преобразовать, при этом работая с одним потоком данных. Даже можете его посети послать или через UART. А тут куча дополнительных сущностный, причем весьма не тривиальных, которые еще могут и эволюционировать. Но главное это убогий синтаксис, тот же perl, gradle и даже pyton на порядки приятнее. Да лучше php написать чем на ps и работать будет на большем количестве платформ.
Так ведь вам ничто не мешает в современном PS полученный откуда-то JSON прогнать через ConvertFrom-Json и получить на выходе объект соответствующей структуры. Или, наоборот — сконвертировать объект в JSON с помощью ConvertTo-Json (или в один из множества других форматов с помощью команд с глаголом ConvertTo) либо просто перегнать объекты в поток символов банальным вызовом метода ToString().
А насчет ситаксиса… Я вот, к примеру, очень мало знаю perl, и скрипты на нем обычно выглядят для меня «перловой кашей», но я понимаю, что это не дает мне никаких оснований объявлять perl плохим, негодным языком — просто этим инструментом я не владею. Почему в случае с PS не происходит то же самое?
Недостаток «архаичных систем» по сравнению с PS, что в них заметно сложнее манипулировать проходящим по конвейеру потоком символов в случае, если этот поток имеет нетривиальную структуру: ему надо устраивать грамматический разбор перед применением, чтобы структурировать. А по конвейеру PS уже идет структурированный поток объектов, имеющих свойства, к которым можно легко и просто обратиться по их имени, чтобы использовать для фильтрации или обработки.
А насчет ситаксиса… Я вот, к примеру, очень мало знаю perl, и скрипты на нем обычно выглядят для меня «перловой кашей», но я понимаю, что это не дает мне никаких оснований объявлять perl плохим, негодным языком — просто этим инструментом я не владею. Почему в случае с PS не происходит то же самое?
Недостаток «архаичных систем» по сравнению с PS, что в них заметно сложнее манипулировать проходящим по конвейеру потоком символов в случае, если этот поток имеет нетривиальную структуру: ему надо устраивать грамматический разбор перед применением, чтобы структурировать. А по конвейеру PS уже идет структурированный поток объектов, имеющих свойства, к которым можно легко и просто обратиться по их имени, чтобы использовать для фильтрации или обработки.
А эквивалент на Poweshell — он еще проще:
Первая команда читает файл целиком в одну строку и кладет ее в конвейер (можно это проверить, передав ее результат в Measure-Object: свойство Count результата будет равно 1), вторая — построчно (в конвейер передаются по одной строки, содержащиеся в файле, проверить можно опять-таки с помощью Measure-Count).
Ну а выдача содержимого конвейера на экран после выполнения команды — это действие Powershell по умолчанию.
$File = 'имя.файла
Get-Content $File -ReadCount 0
Get-Content $File
Первая команда читает файл целиком в одну строку и кладет ее в конвейер (можно это проверить, передав ее результат в Measure-Object: свойство Count результата будет равно 1), вторая — построчно (в конвейер передаются по одной строки, содержащиеся в файле, проверить можно опять-таки с помощью Measure-Count).
Ну а выдача содержимого конвейера на экран после выполнения команды — это действие Powershell по умолчанию.
Ну давайте меряться.
cat "filename"
Ну, давайте :-):
У Get-Content есть и такой псевдоним. И псевдоним type (родом из MS DOS) — тоже еcть.
PS С Get-ChildItem/ls/dir ситуация аналогичная.
cat "filename"
У Get-Content есть и такой псевдоним. И псевдоним type (родом из MS DOS) — тоже еcть.
PS С Get-ChildItem/ls/dir ситуация аналогичная.
Ага. Только пользы от него никакой, потому что ни /proc, ни /sys, ни /dev.
Ну, если посмотреть, что показывает Get-PSDrive, то в PS много разных «дисков» в пространстве имен есть, помимо файловой системы: HKLM+HKCU (это реестр), Env, WSMan. А еcли дополнительные компоненты ОС поставить да модули подключить, то может и кое-что дополнительное появиться. Например — AD: (т. е. — каталог Active Directory, DS или LDS). Или «диск» с конфигурацией службы Information Rights Management (это — одно из основных средств задания этой самой конфигурации).
А вообще-то, для полного доступа к конфигурации локальной системы в Windows gwmi (т.е. Get-WmiObject) есть. И Set-WMIInstance.
PS Да, методы администрирования Windows и Linux — они таки отличаются.
PPS На этом соревнование предлагаю считать законченным и, если хотите — признать вас победителем: я на приз в любой дисциплине соревнований типа Windows vs Linux традиционно не претендую. Но, надеюсь, я вас убедил, что Powerhell — он не такой страшный как вам казалось раньше?
А вообще-то, для полного доступа к конфигурации локальной системы в Windows gwmi (т.е. Get-WmiObject) есть. И Set-WMIInstance.
PS Да, методы администрирования Windows и Linux — они таки отличаются.
PPS На этом соревнование предлагаю считать законченным и, если хотите — признать вас победителем: я на приз в любой дисциплине соревнований типа Windows vs Linux традиционно не претендую. Но, надеюсь, я вас убедил, что Powerhell — он не такой страшный как вам казалось раньше?
Он не страшный. Он уродливый. Я этот поинт с самого начала вёл. Есть языки, которые пишутся с представлением о красоте, а есть языки, в которых "как-то получилось и сойдёт".
«Красота — в глазах смотрящего»((с), AFAIK — перевод с английского фразы О.Уайлда(но это неточно)).
То есть понятие красоты — оно сугубо субъективно.
На этом обсуждение Powershell с вами предлагаю закончить.
Надеюсь, вам никогда не придется администрировать MS Exchange: там Powershell без альтернатив.
То есть понятие красоты — оно сугубо субъективно.
На этом обсуждение Powershell с вами предлагаю закончить.
Надеюсь, вам никогда не придется администрировать MS Exchange: там Powershell без альтернатив.
Ну я бы отметил, что java и c# и не были изначально скриптовыми языками, чем является python изначально. Да, по моим ощущениям они конечно пытаются и в скриптовые языки войти в последнее время многими упрощениями, но это все равно не то.
Это как сравнивать теплое с мягким, натягивать сову на глобус, ну и другие аналогии придумайте. Очень странно предъявы кидать языкам, которые и не были именно для этого предназначены
Я кидаю предъявы не языку, а человеку, который пытается эту монстросити притащить в администрирование и считает, что так и надо.
ровно так же мы можем обсуждать код для автоматического провиза виртуалок в CI, написанный на boost'е в C++. Неподобающий инструмент, провоцирующий невыносимые условия работы.
А чем Powershell монструозен? Да, считаю, что все, что упрощает мне жизнь в администрировании, имеет право на жизнь. Никого пользоваться не заставляю
Я ж показал чем. Ужасный синтаксис, постоянные отсылки объектную модель .net.
Принял. Но какая альтернатива скриптового администрирования Windows?
Как, например, скриптом создать подключение к VPN не через Powershell?
А от .NET тут только Win.forms, который лишь объединяет несколько скриптов в один с выбором действий через «окошко».
Как, например, скриптом создать подключение к VPN не через Powershell?
А от .NET тут только Win.forms, который лишь объединяет несколько скриптов в один с выбором действий через «окошко».
Я последний раз видел винды всерьёз в 2008. В принципе, тот кусок, который мне надо было автоматизировать, мы сделали на winrm, но он оставил примерно такое же ощущение брезгливости и уныния.
Я не знаю ответа "как хорошо и красиво администрировать Windows", и это было одним из ключевых моих мотивов для перехода на Linux. Тогда Ансибла ещё не было. Наверное, сейчас я бы попытался использовать Ансибл.
Если использовать Powershell исключительно как средство доступа к сборкам .NET, то так оно и будет.
Иногда это неизбежно: например, для одновременного доступа к содержимому п/я и к средствам администрирования Exchange нет другого выхода, кроме как использовать Powershell (доступ к администрированию Exchаnge, альтернатив тут нет) и EWS Manged API из .NET (в средствах администрирования Exhange крайне ограничены возможности доступа к содержимому п/я).
Но чаще всего альтернатива есть.
Иногда это неизбежно: например, для одновременного доступа к содержимому п/я и к средствам администрирования Exchange нет другого выхода, кроме как использовать Powershell (доступ к администрированию Exchаnge, альтернатив тут нет) и EWS Manged API из .NET (в средствах администрирования Exhange крайне ограничены возможности доступа к содержимому п/я).
Но чаще всего альтернатива есть.
данные для подключению к клиентам с логинами\паролями в облаке гугл? Окей, думаю они в восторге были-бы, если-б узнали.
PS: вообще удивляет, что люди осуществляющую L3 поддержку, не в состоянии автоматизировать свой труд. На данном уровне, руководитель должен решать только административные вопросы.
У нас в конторе даже специально написано каким приложением пользоватся для обмена паролями.
Блин ну не делайте так. Случайно нажмете на не ту ссылку и ваша таблица будет видна всему интернету
Блин ну не делайте так. Случайно нажмете на не ту ссылку и ваша таблица будет видна всему интернету
А вы не боитесь, что у вас доступы утекут? Начиная с банальной недоработки со стороны Гугла, заканчивая утечкой самой ссылки? Декомпилировать .Net приложение и посмотреть откуда тянутся данные не составит труда, не говоря уже о распространении скрипта в чистом виде
Спасибо, поправил статью, указав, что GD выбран для примера.
Скрипт, естественно, не стоит распространять за пределы собственного использования с оставлением в нем частных данных.
Он предназначен для персонального использования.
С тем же успехом, можно просто передать все имена/пароли/приватные ключи.
Скрипт, естественно, не стоит распространять за пределы собственного использования с оставлением в нем частных данных.
Он предназначен для персонального использования.
С тем же успехом, можно просто передать все имена/пароли/приватные ключи.
Рабочие данные храню не в гугле, а в собственном облаке, но если описывать еще и его, одной статьи не хватит. Впрочем, спасибо за идею, следующая статья будет о быстром разворачивании Nextcloud с ONLYOFFICE
Никто не мешает хранить не в google, а локально, или на своих закрытых ресурсах. Всего-то чутка поправить скрипт.
Данная статья не предназначена для использования as is, а преследует цель показать некоторые приемы работы в powershell
Каждый волен использовать приведенный здесь текст по своему усмотрению.
Никто не мешает хранить не в google, а локально, или на своих закрытых ресурсах. Всего-то чутка поправить скрипт.
Данная статья не предназначена для использования as is, а преследует цель показать некоторые приемы работы в powershell
Каждый волен использовать приведенный здесь текст по своему усмотрению.
Вы IMHO зря не написали об этом в статье — что Google Docs в качестве хранилища тут чисто для примера, что из соображений безопасности секретные данные, вроде логинов и паролей, там лучше бы не хранить, ибо можно нарваться.
Писать такое надо, причем — в начале статьи — ибо редкий гуглящий читает нагугленное до конца. У меня был пример — статья в личном блоге про создание кластера DNS в MS Windows.
Статья — наполовину шуточная: отказоустойчивость в системе DNS отлично обеспечивается другими средствами. И шуточная она именно наполовину, ибо вообще-то иллюстрирует, как можно добавить в кластер MS FT произвольный сервис, вместе с его конфигурацией в файловой системе и в реестре (собственно, для этого она и была написана). А сервис DNS был выбран в качестве примера только потому, что немногим ранее на мой любимый админский форум приперся некий оригинал (то ли неадекват, то ли, типа, тонкий тролль), который требовал, просил и умолял, чтобы его научили созданию кластера DNS — притом, что ему сразу объяснили, как надо делать DNS отказоустойчивым штатными методами.
Так вот, несмотря на примечание в конце статьи о шуточном характере выбранного примера, я регулярно наблюдал попытки использовать эту статью в качестве руководства по развертыванию DNS в кластере — пока, наконец, не написал предупреждение крупными буквами в самом начале статьи.
Писать такое надо, причем — в начале статьи — ибо редкий гуглящий читает нагугленное до конца. У меня был пример — статья в личном блоге про создание кластера DNS в MS Windows.
Статья — наполовину шуточная: отказоустойчивость в системе DNS отлично обеспечивается другими средствами. И шуточная она именно наполовину, ибо вообще-то иллюстрирует, как можно добавить в кластер MS FT произвольный сервис, вместе с его конфигурацией в файловой системе и в реестре (собственно, для этого она и была написана). А сервис DNS был выбран в качестве примера только потому, что немногим ранее на мой любимый админский форум приперся некий оригинал (то ли неадекват, то ли, типа, тонкий тролль), который требовал, просил и умолял, чтобы его научили созданию кластера DNS — притом, что ему сразу объяснили, как надо делать DNS отказоустойчивым штатными методами.
Так вот, несмотря на примечание в конце статьи о шуточном характере выбранного примера, я регулярно наблюдал попытки использовать эту статью в качестве руководства по развертыванию DNS в кластере — пока, наконец, не написал предупреждение крупными буквами в самом начале статьи.
Скриншот работающего приложения с затертыми данными:Все бы ничего, но если вы тестовый гуглодок предоставляете, то и скриншот можно было бы с него сделать. И выглядело бы прилично. А то показывать скриншоты, с затертыми ластиком данными, это прям неуважение к читателям в наше время. Смотрится очень очень плохо.
Да и код под спойлер спрятать неплохо, было бы :)
Это моя первая статья, возможно, что-то не красиво оформил.
Но, расшифруйте, пожалуйста, причём тут текстовый гуглодок?
Скриншоты работы рабочего скрипта, как-то неправильно было бы светить выводимые там данные
Тестовый гуглодок.
Заполнить его, и на его основе сделать скриншот для статьи. Будет просто и наглядно.
Ластик и фильтры в скриншотах делаются в тех редких случаях, когда нужно скрыть логины/пароли/токены/ипы в скриншотах, которые сделаны обычно в рамках траблшутинга/исследования. Делать это нужно очень точечно и что бы было явно видно, что замазано. Иначе получится как у Вас, вроде и интерфейс программы, но на выходе какая не понятная хрень в которой непонятно как отображаются данные, потому что широкими мазками ластиком белому по белому орудовали.
upd.
Увидел исправленный скриншот, спасибо! Теперь сильно нагляднее :)
Заполнить его, и на его основе сделать скриншот для статьи. Будет просто и наглядно.
Ластик и фильтры в скриншотах делаются в тех редких случаях, когда нужно скрыть логины/пароли/токены/ипы в скриншотах, которые сделаны обычно в рамках траблшутинга/исследования. Делать это нужно очень точечно и что бы было явно видно, что замазано. Иначе получится как у Вас, вроде и интерфейс программы, но на выходе какая не понятная хрень в которой непонятно как отображаются данные, потому что широкими мазками ластиком белому по белому орудовали.
upd.
Увидел исправленный скриншот, спасибо! Теперь сильно нагляднее :)
Хрень какая-то, есть же VBScript и редактор для админов www.vbsedit.com с готовыми шаблонами рутинных действий. Там же были и графические приложения hta.
ps: И работает оно даже на xp.
ps: И работает оно даже на xp.
Вы давно в WSH обычный исполняемый файл запускали и его вывод в скрипт возвращали?
ЕМНИП во врмена XP это было нетривиальной задачей, примерно такой же по сложности, как код с SO от amarao выше.
ЕМНИП во врмена XP это было нетривиальной задачей, примерно такой же по сложности, как код с SO от amarao выше.
А что есть какие-то проблемы?
Вот скрипт времён xp
Function TestSpeed(ip)
Set sh=WScript.CreateObject("WScript.Shell")
Set res=sh.Exec("iperf -c " & ip & " -P 5")
out=res.StdOut.ReadAll
Set re=New RegExp
re.Pattern="\[SUM\].*\s([0-9\.]+) Mbits/sec"
re.Global=True
Set m = re.Execute(out)
If m.Count>0 Then
TestSpeed=eval(m(0).Submatches(0))
Else
TestSpeed=-1
MsgBox res.StdErr.ReadAll,48,"Error " & ip
End If
End Function
ip=InputBox("Specify iperf server address ip or hostname", _
"Enter server address", _
"192.168.1.2")
if ip<>"" then
speed=TestSpeed(ip)
if speed>=0 then
MsgBox "Speed = " & speed & " MBits/s",0,"Testing " & ip
end if
end if
Помню, что были. Потому что самому приходилось их обходить. Но, возможно, это было в Win2K, в изначальной инкарнации WSH и его объектов. Честно говоря, когда появилось свойство, автоматически отслеживающее StdOut, я не помню, а смотреть сейчас — слишком трудоемко. Мне проще признать вашу правоту в данном вопросе.
Совсем не по теме. Vbscript ну совсем другое.
Как в нем создать и управлять vpn-соединениями? Как передавать параметры в winbox, например?
Не читал, но осуждаю?
Как в нем создать и управлять vpn-соединениями?
rasdial?
Не знаю как в winbox, но в линухе есть expect и там на чистом tcl-е можно общаться с сетевым оборудованием типа цисок вполне комфортно.
Какая разница? Точно так же как в ps можно дергать куски .net, которые дергают WinApi, в vbscript можно было дергать WinApi напрямую. Иногда так даже надежнее. Но согласен, с предыдущими коментариями. PowerShell как морская свинка — ни к свиньям не относится, ни к морю. Для shell переусложнен, для ЯП слишком примитивен, те же python/perl/lua позволяют создавать более продвинутые приложения.
Да что там сложного то?
Довольно красиво.
Например, удалить все снапшоты виртуальных машин старше 5 дней и создать ежедневный снапшот можно всего двумя строчками, причем очень понятными
Довольно красиво.
Например, удалить все снапшоты виртуальных машин старше 5 дней и создать ежедневный снапшот можно всего двумя строчками, причем очень понятными
Get-VMSnapshot -VMName *| Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-5) } | Remove-VMSnapshot
Get-VM * | Checkpoint-VM -SnapshotName "Daily Snapshot $((Get-Date).toshortdatestring())"Ничего, что вы привели пример специфичного приложения для которого производитель написал командлеты облегчающие работу? С таким же успехомможно написать на C# небольшое приложение приложение удаляющее снапшоты, вызвать его из vbs или cmd и сказать смотрите как просто и коротко.
Опять ничего не понял, причем тут c#? Да, теперь для всего в Windows 10/Server есть командлеты. И этим Powershell очень удобен. Зачем что-то писать на C# и вызывать в cmd, если это уже реализовано и документировано?
Сдается мне, что мы на разных языках говорим
Сдается мне, что мы на разных языках говорим
Затем что с shell, прочитав справку, разберется даже не подготовленный человек. А приведенный вами пример, для меня не работающего с ps выглядит не намного понятнее однострочника на perl или python. Т. е. для начала придется прочитать мануалы по Get-VMSnapshot, Get-Date, Remove-VMSnapshot,Checkpoint-VM. Потому и говорю, для shell слишком сложный. Vbscript никто shell не называл, хотя он на порядок проще.
По мне так нет ничего проще набрать
Или
Раз это это для вас сложно, имеет смысл прекратить никуда не ведущую дискуссию
Get-Help Get-Date -onlineИли
Get-Help Get-Date -full |moreРаз это это для вас сложно, имеет смысл прекратить никуда не ведущую дискуссию
Не говоря уже о переносимости. Что это за shell код для которого сильно зависит от версии? В приведенном вами примере Get-Date -AsUTC есть в current, но нет в LTS. Get-VMSnapshot так и совсем должен быть установлен и разные в разных версиях windows содержит разный набор параметров. Потому и говорю еще раз. PowerShell не shell, а полноценный скриптовый ЯП со специфичным синтаксисом похожим на shell. Но в этом качестве он уступает многим ЯП например в управлении потоками. Не говоря уже о том, что ни один shell не съедает 61 МБ памяти после пары вызовов Get-Help.
Точно так же как в ps можно дергать куски .net, которые дергают WinApi, в vbscript можно было дергать WinApi напрямую.
Утверждение неверное.
Напрямую скриптовые языки, реализованные на базе ActiveScript — кроме vbscript в стандартной поставке был еще JS(и я предпочитал именно его, ибо с юности не любил Basic), а третьи фирмы реализовали и другие языки, из коих мне помнятся Perl и REXX — умели работать только с COM Automation, т.е. объектами классов COM, реализующими интерфейс IDispatch. Для доступа к дргим классам COM из скриптов требовались обертки: например, из скриптов нельзя было напрямую работать с такими базирующимися на COM API, как OLE DB или MAPI, нужны были дополнительные прослойки (ADO и CDO, соответственно). Что касается .NET, то из скриптов ActiveScript доступны компоненты, которые написаны специально для взаимодействия с COM Automation (подробности я с вашего позволения опущу).
С Win32 API была ровно та же ситуация: для обращения к ним требовались обертки, реализующие IDispatch с методами, отображающимися, на функции Win32 API — как, например, здесь (обертка там сделана на VB)
В Powershell с этим сильно легче: из него доступны объекты очень многих (за «всех» не скажу) классов .NET, а также — все «родные»(Native) API, доступные через Interop: в частости — и объекты COM Automation, и функции Win32 API.
Другое дело, что Powershell как инструмент для создания приложений, в общем-то, не предназначен, он заточен для использования в другой сфере — адмистрировании (в том числе — автоматизации администрирования). Не скажу, что он для этого идеален (например, команды можно было бы сделать и покороче — впрочем, это вполне лечится псевдонимами), но — весьма удобен (лично мне, по крайней мере): это я вам как практик, довольно долго работавший с администрированием AD и MS Exchange говорю, со скриптами на базе ActiveScript (с использованием ADSI и CDOEXM, чем приходилось пользоваться до PS) — не сравнить.
Это подключиться, а как создать? И как прописать для конкретного соединения маршруты?
В скриншоте имя клиента справа вверху Вы, видимо, забыли затереть? А в интернете ищется на раз.
P.S. Сам недавно на PowerShell сделал проверку на вирусы передаваемых файлов и передачу отчета во внешнюю программу. Очень неплохо получилось!
В Вашем случае — отличное решение. Что называется, дешево и сердито! Экономия телодвижений сотрудников при минимальных затратах выливается в существенный прирост эффективности предприятия в целом. ))
Попробуйте переписать GUI на WPF используя XAML, у вас будет два файла — один с кодом, второй с разметкой. На мой взгляд разметка XAML удобнее
чем WinForm
В качестве плюса вы получите относительное позиционирование элементов при разном размере окна и разрешений экрана.
<Button Name="ExitButton" Content="Выход" Click="ExitButton_OnClick" TabIndex="15"/>
чем WinForm
$buttonВыход.Location = '7, 125'
$buttonВыход.Name = 'buttonВыход'
$buttonВыход.Size = '133, 23'
$buttonВыход.TabIndex = 15
$buttonВыход.Text = 'Выход'
$buttonВыход.UseCompatibleTextRendering = $True
$buttonВыход.UseVisualStyleBackColor = $True
$buttonВыход.add_Click($buttonВыход_Click)В качестве плюса вы получите относительное позиционирование элементов при разном размере окна и разрешений экрана.
Спасибо. Попробую
В качестве плюса вы получите относительное позиционирование элементов при разном размере окна и разрешений экрана.
Это и на вин-формах без проблем делается...
Плюс WPF гораздо гибче в плане дизайна, насколько я понимаю. Попробовал и то, и другое, остановился на WPF для GUI скриптов на PowerShell.
Я тоже пробовал прикручивать к PS интерфейс, но не нашел простого решения проблемы фриза формы при длительных вычислительных и сетевых операциях, пришлось переписать пару утилит на C# с async/await.
Все-таки, PS, не совсем для этого. Он больше скритовой язык.
Всё таки microsoft уже столько технологий для одного и того же выкатила и не одну довести до нормального состояния не может, постоянно что-то новое рожает.
Этот чудо скриптовый язык из той же оперы.
Этот чудо скриптовый язык из той же оперы.
Не согласен. Я с PS по роду работы имел дела много и именно в области его применимости. И, в целом, вполне этим иснтрументом доволен. Надо только правильно понимать только эту самую область применимости: интерактивные ad hoc мини-программы и небольшие по объему скрипты. В этой области PS по сравнению с JS(в ActiveScript, в частности WSH)+COM Automation (это набор иснтрументов, закрывавший у MS примерно тот же круг задач до PS) — небо и земля по удобству использования.
А вот писать сколь-нибудь сложные программы — с этим на PS сложнее.
PS Прикручивать к PS формы я не пробовал (хотя в WinForms на C# вполне умею).
Во времена господства ActiveScript в администрировании Windows я для таких надобностей (была, к примеру, задача — дать девочкам-операторам простой интерфейс для заполнения нужных атрибутов пользователей в AD, чтобы они в адресной книге видны были, на то время, пока программисты интеграцию с кадровой БД не прикрутят) использовал Delphi: из нее объекты COM Automation тоже вызывались легко и непринужденно, а с тех пор подобных задач мне не встречалось.
PPS Сравнивать администрирование Windows с помощью PS и Unix/Linux с помощью shell и стандартного набора команд не берусь (у меня очень мало опыта второго: несколько лет поддержки пары серверов, настроенных, к тому же, другими людьми — это дает слишком мало матриала для сравнения).
А вот писать сколь-нибудь сложные программы — с этим на PS сложнее.
PS Прикручивать к PS формы я не пробовал (хотя в WinForms на C# вполне умею).
Во времена господства ActiveScript в администрировании Windows я для таких надобностей (была, к примеру, задача — дать девочкам-операторам простой интерфейс для заполнения нужных атрибутов пользователей в AD, чтобы они в адресной книге видны были, на то время, пока программисты интеграцию с кадровой БД не прикрутят) использовал Delphi: из нее объекты COM Automation тоже вызывались легко и непринужденно, а с тех пор подобных задач мне не встречалось.
PPS Сравнивать администрирование Windows с помощью PS и Unix/Linux с помощью shell и стандартного набора команд не берусь (у меня очень мало опыта второго: несколько лет поддержки пары серверов, настроенных, к тому же, другими людьми — это дает слишком мало матриала для сравнения).
В настоящее время PowerShell, на мой взгляд, закрывает процентов 90 задач администрирования в экосистеме MS. Кроме того, многие другие вендоры выпускают свои модули для PS: VMware, Citrix, Amazon и др. У MS далеко не все продукты получаются удачными, но PS вышел таким, если его рассматривать как инструмент администрирования и автоматизации, для чего он и предназначен.
да, там приходится либо форму в параллельный поток выносить, либо таски. И то и другой вариант неудобны. Тоже самое, только еще неудобнее если грузить XAML (WPF) вместо WinForms. Я попробовал все эти варианты.
Remote desktop manager. Умеет работать с облаками разными, можно натравить кучу пользователей на один файл скажем на сетевой шаре. Ну и кроме рдп много что умеет. В том числе умеет всякие vpn сам поднимать, вроде даже маршруты настраивать. В контексте пары пользователей вполне и freeшной версией пользоваться.
А это как по мне для 3 линии тп... Ну тока чтобы до завтра не умереть...
Хорошая программа. Не спорю.
Задача статьи была показать некие приемы работы в PS, и показать что PS не cmd, умеет не только dir c::)
Да нет, задача у вас стояла другая:
Я не спорю, PS — крут (может знаете как через PS заполнить Имя запускаемой программы и рабочий каталог для пользователя в терминале (управление — пользователи — среда)). Но решать им подобные задачи, когда есть ворох готового… Хуже наверное только те кто в 2021 году делают java приложения для решения задач на всю страну (((
PS. Без обид. У меня ни каких претензий, я просто высказываю свое мнение.
Работая в компании IT-аутсорса в качестве руководителя 3 линии поддержки, задумался, как автоматизировать подключение сотрудников по RDP, через VPN к серверам десятков клиентов.
Я не спорю, PS — крут (может знаете как через PS заполнить Имя запускаемой программы и рабочий каталог для пользователя в терминале (управление — пользователи — среда)). Но решать им подобные задачи, когда есть ворох готового… Хуже наверное только те кто в 2021 году делают java приложения для решения задач на всю страну (((
PS. Без обид. У меня ни каких претензий, я просто высказываю свое мнение.
Какие обиды :)
Задача статьи, я имел ввиду.
А рабочая задача - упростить себе работу.
Remote desktop manager, конечно крут, но слишком тяжел и дорог.
К тому же, у нас штат 1Сников, админов 1 и 3 линий и прочих, кому надо быстро подключиться к RDP через VPN или к Mikrotik клиента.
Плюс, вывод самой необходимой информации о клиенте в окошко (серверы, подсети, вебморды etc).
Вот и написал небольшой мультитул, практически не имея опыта в программировании, на основании таких же статей по PS, а уже потом решил поделиться с сообществом, поскольку мне PS для решения таких задач понравился.
Но в реалии, буду уходить от VPN в сторону SSH-туннелей для админских подключений.
UFO just landed and posted this here
Sign up to leave a comment.
Powershell настоящий язык программирования. Скрипт оптимизации рутины в техподдержке