Открыть список
Как стать автором
Обновить

Комментарии 35

PowerShell был создан как попытка замены неудобоваримого CMD для чайников и, одновременно, прибить наконец костыль REXX, как неканоничный. Получилось то, что получилось. Но большинство решаемых с его помощью задач вполне реализуемы в рамках CMD (нетривиально) и REXX (не поддерживается в современных виндах).

P.S. Язык ли он программирования? В равной степени, как и другой скриптовый, просто со своеобразным применением, что свойственно им всем.
Довольно странная формулировка поста.
Главный вопрос, который возникает при чтении статьи так и остался без ответа:

Чем PowerShell поможет мне в конкретных прикладных задачах, и при каких условиях стоит выбирать его вместо того же C#?
Например, у меня была необходимость написать некоторую программу на компьютере с максимально урезанными правами. Так что мне пришлось воспользоваться банальной IDE из пакета MS офиса с встроенным VisualBasic.
Какая разница является или нет?
Задачи решает? Решает. А кто как называет его «скриптовый язык» или «язык программирования» или «средство управления» вопрос десятый. Не спорьте о терминах, а договаривайтесь о них.
PowerShell может использовать классы .Net, так что по потенциальным возможностям он не уступает C#. Но в первую очередь это всё же командный процессор, призванный заменить CMD (при этом сохраняя частичную совместимость команд). То есть, программный клей для автоматизации работы других инструментов, как сам сmd или sh.

Можете ли вы на нём написать, например, текстовый редактор? Можете. Но зачем, если это проще и быстрее сделать на том же С#?
Но зачем, если 99.9% решаемых фактически задач вполне решаемы на CMD?

Простите за тавтологию.

И, кстати можно и в планировщик «забить», и самим CMD сделать «частью плана»,,,
Вопрос в сложности и скорости решения.
и Cmd, и PowerShell «заточены» под исполнение внешних приложений. Но когда мне понадобилось обработать группу файлов (удалить часть файлов по списку), разобраться в работе PowerShell было проще, чем вспомнить как использовать цикл в Cmd.

В C# можно решить те же задачи, но при этом вместо однострочного вызова вы получаете блок кода с инициализацией вызова, работой stdin/stdout (если ещё оно будет работать, многие консольные приложения без бубна не пишут вывод в реальном времени).

Каждому инструменту своя задача.
Для тех, кто родился в 201х — PowerShell проще, а для тех, кто родился в 80х — CMD привычнее.

P.S. Удалить «часть файлов по списку» и в CMD делается одной строчкой, вне зависимости от верочтности включений/исключений.

ss64.com закрывает 99,9% зависимости от хелпа.
Так же как и в PS. Назовём это «удалить часть файлов по списку*». Это краткое версия описания задачи. В скрипте нужно было скопировать часть файлов, за исключением некоторого списка. Часть deployment-скрипта, включающего работу с git, реестром и архивирование.

Я конечно могу разобраться и написать всё это для cmd, но даже установка cygwin и использование sh вместо bat — продуктивнее (да, я делал это под Win XP).
Ну вот и ответ :)

Оно возможно. PS сделал это проще чем в CMD и не так как в REXX.

Есть еще один маленький нюанс. Сейчас все ратуют за продуктивность. Продуктивность CMD была бы меньше, чем PS? Не думаю…

P.S. Самый крупный мой BAT/CMD переваливает за 200 строк.
Всё таки обсуждение PS vs. BAT более актуально, чем PS vs. C#
C# и PowerShell — взаимодополняющие инструменты для разных задач.
PowerShell и BAT — новый инструмент разработанный на смену старому.

> Есть еще один маленький нюанс. Сейчас все ратуют за продуктивность. Продуктивность CMD была бы меньше, чем PS? Не думаю…

Я всё таки поспорю, что будет: что в bash, что в PS мне не нужно заморачиваться, сколько же '%' всё таки мне нужно поставить, чтобы переменная корректно прочиталась/обновилась.
BAT выглядит как постепенные наслоения… синтаксиса, постепенно эволюционировавшие в течении многих. PS же, помимо всего прочего, взгляд на имеющийся опыт и сглаживание существующих углов.

Скрипт, который я упоминал (отличный образчик stackoverflow-программирования):
github.com/krypt-lynx/RWLayout/blob/master/Deploy/Deploy.ps1
Продуктивность CMD была бы меньше, чем PS? Не думаю…


Ну сколько например на CMD займёт такая задача как разбор XML?

Или например написать систему, которая будет (правильно) мигрировать виртуалки туда-сюда.

Или как на cmd установить обновления через Windows Update, но выборочно, не все доступные?
Но зачем, если 99.9% решаемых фактически задач вполне решаемы на CMD?

Ну да, ну да. Попробуй в cmd хотя бы вывести на консоль, какой день недели был вчера. А про всякий WMI/CIM, PowerShell remoting, и прочее я даже и упоминать не стану.

Windows — это компьютерная программа?
Powershell является скриптовым языком программирования, разработанным как консольная оболочка операционной системы.
Понятно что на нем можно программировать. И понятно, что его специально разрабатывали для автоматизации различных процессов, для чего было сделано множество инструментов для работы с API операционки.

По замыслу архитекторов из MS они решили хорошие ламповые перенаправления потоков сделать как перенаправление объектов.
Этим они с одной стороны перекрыли путь кроссплатформенной совместимости, но убрали много ненужного парсинга.

Я понимаю их решение, но linux way мне нравится гораздо больше.

Тем не менее вопрос не в том, является или не является — конечно является.
И вопрос не в том, лучше он какого-нить питона или перла — это не универсальный скриптовый язык, а оболочка операционки от создателя операционки, и возможностей по оперированию windows-related вещей в нем ожидается больше, чем от универсальных языков сторонних производителей.
Ну а наличие большого количества инструментов для создания полноценных приложений — это плюс, и возможность выбора, а вот призывать на нем писать — не стоит.
перекрыли путь кроссплатформенной совместимости

Как именно? PowerShell же — кроссплатформенный язык
но на линуксе не будет работать много вещей, заточенных под win, а их там очень много.

Это конечно не совсем точный пример, но представьте, что баш перенесли на винду, а gnu tools забыли. Что-то под виндой найдется свое, но…
они решили хорошие ламповые перенаправления потоков сделать как перенаправление объектов.
Передача объектов по пайплайну — это самое лучшее что могло случится с командной строкой вне зависимости от ОС. То что раньше занимало на sh/cmd десятки строк и требовало создания промежуточных файлов для перелива данных сейчас можно просто решить одной строкой. Взял данные с лога в виде объектов, отфильтровал, отсортировал, выбрал нужные элементы отвечающие условиям и положил в нужно тебе формате и нужно кодировке — и все это одной строкой.
Но написать свой собственный кастомный инструмент на коленке — уже не выйдет, надо в программировании разбираться побольше.
Также сложно внедрить сторонние кроссплатформенные решения.

А в баш можно внедрять многие вещи, которые вообще не думали что их будет кто-то внедрять.
Также сложно внедрить сторонние кроссплатформенные решения.

В смысле? Если ты про PowerShell на Linux, так он там уже три года как работать может.

но на линуксе не будет работать много вещей, заточенных под win, а их там очень много.

Не могу понять. Зачем на линуксе нужны "вещи заточенные под win"? Пускай себе не работают.

Пускай себе не работают.

Это мешает пользоваться повершеллом на линуксе.
Например, сервер на линуксе, и куча виндовых машин через ldap
хочу собрать реестр с разных машин и что-то с ним сделать
а командлета для работы с реестром на линуксе нет

Или какие-то проблемы с case-sensetive штуками

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

Чем мешает? Не пользуйся под Линуксом вещами специфичными для Win. Кто-то насильно заставляет это делать, что ли?

Я так полагаю, под Linux нет возможности подключиться к удалённому реестру? Что скорее проблема отсутствия инструментария, чем проблема PowerShell в частности. В PowerShell вполне возможно добавить кастромный командлет.

Я не знаю технических деталей, как устроено подкулючение к удаленному реестру из Windows, но, подозреваю, что эта фича так же специфична для Windows, как и сам реестр. Впрочем, думаю, что через CIM это вполне возможно, т.к. это технология кроссплатформенная.

командлета для работы с реестром на линуксе нет
зато есть remote session
Но написать свой собственный кастомный инструмент на коленке — уже не выйдет, надо в программировании разбираться побольше.

Строка — это частный случай объекта. Строками никто не запрещал пользоваться. Появилась новая возможность, старая не исчезла

Я так и не сподобился освоить PowerShell, показалось сложным. Я не администратор, просто программист и целевая платформа у меня юниксоподобные системы, линукс, хотя и приходится работать под windows, так как политика компании такая. PowerShell конечно приятен тем, что интегрирован в систему, но с другой стороны это его и ограничивает. Хотя наверняка его можно и под linux поставить. Только кому это надо если, большинство скриптов на bash написано. Вот потому WSL зашло мне. Больше ничего и не надо. Вполне годится для автоматизации каких то своих задач.
Является или нет PowerShell языком программирования — на самом деле эта информация никакой особой полезности не несет. Важно какие задачи он может выполнять.
Для решения задач администрирования и интеграционного скриптинга PS вполне подходит, пайпы — очень удобный механизм, который делает код крайне компактным, также в PS много готовых полезных командлетов для управления ОС, WMI, SCCM в том числе удаленного. Есть не мало расширений, которые добавляют новые командлеты для управления системами различных вендоров (наприме VMware Veeam).
Основной минус PS — низкая производительность. И чем больше в коде пайпов, тем медленнее он работает ( циклы % и условия? особенно). Прискорбно, но приходится менять удобство и компактность на производительность (но есть и плюсы — код без них, вероятно, более понятный), использовать различные ухищрения типа класса ArrayList вместо обычных, хэшировать крупные массивы для быстрой обработки, прибегать к классам LINQ из C# для быстрого определения уникальных записей (хотя казалось бы есть готовые командлеты, но работают медленно) и т.д.
Также есть опыт использования PS для разработки небольших программ с текстовым интерфейсом — вполне себе неплохо работает, параллельные вычисления даже использовал для быстрого опроса большого числа рабочих мест, с взаимодействием с БД также особых проблем не было (не ORM конечно как на C# но таких задач и не стояло)

меня сама идея передачи объектов восхитила. В отличие от убогого «все есть файл», тут «все есть объект», где кроме собственно потока данных есть еще и свойства (метаданные).
Конечно объекты можно сериализировать в XML, JSON или любой другой формат чтобы получить обычный поток данных. Но в PowerShell это обычно не нужно. А поскольку это часть .NET, то легко включать .NET классы прямо в скрипт и которые компилируются в DLL. Можно в WINAPI через .NET обращаться. Поэтому «скрипты» получаются весьма могучими. Правда UI не очень удобно в рукопашную делать. Обычно это типа WinForms, но и XAML (WPF) можно приделывать. В общем, самый большой скрипт у меня давно уже перевалил за 100КБ.
Самое важное отличие, от отсутствия которого страдают все доисторические шеллы — отказ от автоматической разбивки строки на список строк при раскрытии значения переменной в аргументах вызова программы.
Очевидно, что PowerShell не является языком программирования.
Смотрим Википедию: «PowerShell — расширяемое средство автоматизации от Microsoft с открытым исходным кодом[2], состоящее из оболочки с интерфейсом командной строки и сопутствующего языка сценариев.»
Вот язык сценариев PowerShell — это язык программирования.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации
Представитель
ruvds

Блог на Хабре