Я обсуждаю, следует ли изучать PowerShell или просто придерживаться Cygwin/скрипты Perl/Unix shell и т.д.
Преимущество PowerShell заключается в том, что скрипты могут быть более легко использованы товарищами по команде, у которых нет Cygwin; однако, я не знаю, действительно ли я буду писать много сценариев общего назначения, или если бы люди даже использовали их.
Unix-скрипты настолько мощные, что PowerShell подходит достаточно близко, чтобы гарантировать переключение?
Вот некоторые из конкретных вещей (или эквивалентов), которые я бы искал в PowerShell:
Инструменты - это просто инструменты.
Они помогают или нет.
Вам нужна помощь или нет.
Если вы знаете Unix, и эти инструменты делают то, что вам нужно для Windows, то вы счастливый парень, и вам не нужно изучать PowerShell (если вы не хотите исследовать).
Мое первоначальное намерение состояло в том, чтобы включить набор инструментов Unix в Windows и сделать с ним (некоторые из нас в команде имеют глубокие фоны Unix и здоровую дозу уважения к этому сообществу). Я обнаружил, что это не очень помогли. Причина этого заключается в том, что awk/grep/sed не работают против COM, WMI, ADSI, реестра, хранилища сертификатов и т.д. И т.д. Другими словами, UNIX представляет собой целую экосистему, настроенную вокруг текстовых файлов. Таким образом, инструменты обработки текстов являются эффективными инструментами управления. Windows - это совершенно другая экосистема, настроенная на API и объекты. Вот почему мы изобрели PowerShell.
Я думаю, что вы обнаружите, что будет много случаев, когда обработка текста не даст вам то, что вы хотите в Windows. В этот момент вы захотите забрать PowerShell. ПРИМЕЧАНИЕ. Это не все или ничего. В PowerShell вы можете обратиться к своим инструментам Unix (и использовать их текстовый процесс или обработку текста PowerShell). Также вы можете вызвать PowerShell из своих инструментов Unix и получить текст.
Опять же - здесь нет религии - мы сосредоточены на предоставлении вам инструментов, необходимых для успеха. Вот почему мы так увлечены отзывами. Сообщите нам, где мы падаем на работу или где у вас нет необходимого инструмента, и мы поместим его в список и доберемся до него. Честно говоря, мы выкапываем себя из 30-летней дыры, так что это займет некоторое время. Тем не менее, если вы подберете бета-версию Windows Server 2008/R2 и/или бета-версии наших серверных продуктов, я думаю, вы будете потрясенный тем, насколько быстро это отверстие заполняется.
Что касается использования - на сегодняшний день у нас было 3,5 миллиона загрузок. Это не включает людей, использующих его в Windows Server 2008, потому что он включен как дополнительный компонент и не требует загрузки. V2 будет поставляться во всех версиях Windows. Он будет по умолчанию для всех выпусков, кроме ядра ядра, где он является необязательным компонентом. Вскоре после выхода Windows 7/Windows Server 2008 R2 мы сделаем V2 доступным на всех платформах XP и выше. Другими словами - ваши инвестиции в обучение будут применимы к очень большому числу машин/сред.
Последний комментарий. Если/когда вы начнете изучать PowerShell, я думаю, вы будете очень довольны. Большая часть дизайна сильно зависит от наших фоновых рисунков Unix, поэтому, когда мы совсем разные, вы очень быстро подберете его (после того, как вы передумаете, что это не Unix:-)). Мы знаем, что у людей очень ограниченный бюджет для обучения - вот почему мы являемся супер-жесткими принципами согласованности. Вы собираетесь чему-то научиться, а затем будете использовать его снова и снова.
Эксперимент! Наслаждайтесь! Engage!
ОператорGrep
Select-String
и -match
работают с регулярными выражениями. Также вы можете напрямую использовать поддержку .NET regex для более сложных функций.
сортировать
Sort-Object
более мощный (чем я помню * nix sort
). Разрешение многоуровневой сортировки на произвольные выражения. Здесь помогает обслуживание базового типа PSH; например a DateTime
свойство будет сортироваться как DateTime
без необходимости форматирования в отсортированный формат.
Uniq
Select-Object -Unique
Perl (как близко PowerShell приходит к возможностям Perl?)
В терминах Perl широта библиотек поддержки конкретных доменов: нигде не закрыта (пока).
Для общего программирования PSH, безусловно, более сплочен и последователен, и его проще распространять. Единственный пробел для текстового перебора - это что-то, что эквивалентно оператору perl ..
.
AWK
Это было достаточно долго, поскольку awk (должно быть > 18 лет, так как позже я просто использовал perl), поэтому не могу комментировать.
Сед
[См. выше]
(команда, предоставляющая информацию о файле)
Сила PSH здесь заключается не столько в том, что она может делать с объектами файловой системы (и здесь она получает полную информацию, dir
возвращает объекты FileInfo
или FolderInfo
) - это вся модель поставщика.
Вы можете обращаться с реестром, хранилищем сертификатов, сервером SQL Server, IE RSS и т.д. как пространство объектов, которое можно перемещать с помощью тех же командлетов, что и файловая система.
PSH - это, безусловно, путь вперед в Windows. MS сделали его частью своих требований к будущим не-домашним продуктам. Следовательно, богатая поддержка в Exchange, поддержка SQL Server, это только расширится.
Недавним примером этого является TFS PowerToys. Многие операции с клиентом TFS выполняются без необходимости запуска tf.exe каждый раз (для чего требуется новое подключение к серверу TFS и т.д.), И, что особенно важно, обрабатывать данные. Помимо широкого доступа ко всему API-интерфейсу TFS для более подробной информации, чем в Team Explorer TF.exe.
Как кто-то, кто сфокусировался на развитии предприятия Windows с 1997 по 2010 год, очевидным ответом будет Powershell по всем веским причинам, приведенным выше (например, это часть корпоративной стратегии MS, она хорошо интегрируется с Windows/COM/.NET, а использование объектов вместо файлов обеспечивает "более богатую" модель кодирования). По этой причине я использовал и продвигал Powershell последние 2 года или около того, с явным убеждением, что я следую "Слову Билла".
Однако, как прагматик, я больше не уверен, что Powershell - такой отличный ответ. Хотя это отличный инструмент Windows и обеспечивает необходимый шаг к заполнению исторической дыры, которая является командной строкой Window, так как мы все наблюдаем за захватом MS на потребительском компьютерном проскальзывании, кажется, все более вероятным, что MS имеет огромную битву впереди, чтобы поддерживать ее ОС как важно для предприятия будущего.
Действительно, учитывая, что я нахожу, что моя работа все чаще встречается в гетерогенных средах, мне гораздо удобнее использовать скрипты bash на данный момент, поскольку они работают не только на Linux, Solaris и Mac OS X, но они также работайте с помощью Cygwin-on Windows.
Итак, если вы согласны с тем, что будущее ОС скорее коммодитируется, а не монополизировано, то, похоже, имеет смысл выбрать гибкую стратегию инструмента разработки, которая, если это возможно, будет избегать использования проприетарных инструментов. Если, однако, вы видите, что в вашем будущем доминируют все-это-Редмонд, тогда отправляйтесь в Powershell.
Я использовал немного PowerShell для автоматизации script. Хотя очень приятно, что среда, по-видимому, была продумана гораздо больше, чем оболочки Unix, на практике использование объектов вместо текстовых потоков гораздо более неуклюжие, и многие объекты Unix, которые были разработаны за последние 30 лет по-прежнему отсутствуют.
Cygwin по-прежнему является моей средой сценариев выбора для хостов Windows. Это, безусловно, превосходит альтернативы с точки зрения достижения цели.
Я только недавно начал заниматься в PS с любой степенью серьезности. Хотя за последние семь лет я работал в почти исключительно среде на базе Windows, я исхожу из фона Unix и постоянно пытаюсь использовать "Unix-fy" опыт взаимодействия с Windows. Это разочаровывает, если не сказать больше.
Справедливо сравнивать PS с чем-то вроде Bash, tcsh или zsh, поскольку утилиты вроде grep, sed, awk, find и т.д., строго говоря, не являются частью оболочки; однако они всегда будут частью любой среды Unix. Тем не менее, команда PS, такая как Select-String, имеет очень похожую функцию grep и поставляется в виде основного модуля в PS... поэтому линии могут быть немного размыты.
Я думаю, что ключевым моментом является культура, и тот факт, что соответствующие наборы инструментов будут воплощать их соответствующие культуры:
Административный (и на протяжении многих лет) интерфейс Unix традиционно является командной строкой и виртуальным терминалом. Windows запускалась как графический интерфейс, и административные функции только недавно начали отходить от использования исключительно GUI. Мы можем ожидать, что опыт Unix в командной строке будет более богатым, более зрелым, учитывая значительное преимущество в PS, и мой опыт соответствует этому. По этому опыту:
Административный опыт Unix направлен на то, чтобы сделать вещи легкими в минимальном количестве ключевых штрихов; это, вероятно, связано с исторической ситуацией, связанной с администрированием сервера по медленному подключению удаленного доступа 9600 бод. Теперь PS имеет псевдонимы, которые идут длинным путем, чтобы обойти довольно подробный Verb-Noun стандарт, но знакомство с этими псевдонимами немного больно (кто-то знает чего-то лучше, чем: alias | where {$_.ResolvedCommandName -eq "<command>"}
?).
Пример богатого способа управления историей:
iptables
команды часто длинны, и повторять их с небольшими различиями было бы болью, если бы не одна из многих опрятных черт истории манипуляции, встроенная в Bash, поэтому вставьте правило iptables, как показано ниже:
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT
второй раз для другой камеры ( "camera-2
" ) - это всего лишь случай выдачи:
!!:s/-1-/-2-/:s/50/51
что означает "выполнить предыдущую команду, но замените -1-
на -2-
и 50
на 51
.
Опыт Unix оптимизирован для сенсорных машинистов; можно в значительной степени сделать все, не покидая "домашнего" положения. Например, в Bash, используя привязки клавиш Emacs (да, Bash также поддерживает привязки vi), циклическое перемещение по истории выполняется с помощью Ctrl-P и Ctrl-N, в то время как переход к началу и концу строки выполняется с помощью Ctrl-A и Ctrl-E соответственно... и это определенно на этом не заканчивается. Попробуйте даже простейшую навигацию в консоли PS, не перемещаясь из исходной позиции, и у вас проблемы.
/dev
и /proc
) или (не объектно-ориентированный) вызов библиотеки C-стиля. Неудивительно, что опыт сценариев соответствует их соответствующим парадигмам ОС. PSпо своей природе структурирован (все - объект) и Bash -и-друзья на основе файлов. Структурированный API, который находится в распоряжении программиста PS, обширен (в основном, соответствует обширности существующего набора стандартных интерфейсов COM и .NET).Короче говоря, хотя возможности сценариев PS, возможно, более мощные, чем Bash (особенно если вы рассматриваете доступность .NET BCL), интерактивный опыт значительно слабее, особенно если вы используете его с полностью ориентированной на клавиатуру консольной точки зрения (как и у многих Unix-головок).
alias -Definition *property
(или любой другой шаблон)? Я думаю, что проблема с вашим ответом заключается в том, что вы объединяете оболочку и консоль: помните, что у вас есть выбор консолей с различными вариантами редактирования. Они намеренно оставили редактирование консоли DOS неработающим, чтобы побудить людей использовать другие консоли, такие как ISE.
!!
пример может быть записан в Powershell как (h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
но стрелку вверх и редактировать проще для одной команды. Если вы хотите сделать это с помощью множества команд, думаю, Powershell победит. Чтобы повторить 10 команд, заканчивающихся на команде # 255, с вашими правками: (h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Также история Powershell позволяет вам делать что-то неслыханное в оболочках Linux; если вы задаетесь вопросом ретроспективно, сколько времени потребовалось команде для выполнения: h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
Много замечательных ответов, вот мой прием. PS готов, если вы... Пример
grep = "Select-String -Pattern"
sort = "Sort-Object"
uniq = "Get-Unique"
file = "Get-Item"
cat = "Get-Content"
Perl/Awk/Sed - это не команда, но утилиты, следовательно, трудно сравнивать, но вы можете делать почти все в Powershell.
sls
, sort
, gu
, gi
, gc
соответственно. Длинные удобочитаемые имена, которые могут содержать табуляцию, и короткие имена с возможностью ввода в одной системе. Это удобный для вас прогресс.
Я не очень опытный пользователь PowerShell каким-либо образом, но немного того, что я выставил, впечатлило меня. Вы можете связать встроенные командлеты вместе, чтобы сделать что угодно, что вы могли бы сделать в приглашении Unix, и есть дополнительная доработка для выполнения таких операций, как экспорт в CSV, HTML-таблицы и более глубокие типы sys-admin рабочие места. И если вам действительно нужно что-то вроде sed, всегда UnixUtils или GnuWin32, которые вы могли бы легко интегрировать с Powershell.
Как давний пользователь Unix, я, однако, немного беспокоился о том, чтобы привыкнуть к схеме именования команд, и я, конечно, выиграл бы от этого больше, если бы знал больше .NET.
Так что, по сути, я говорю, что это стоит того, чтобы изучить его, если проблема с Windows не создает проблем.
Если вам нравится сценарий оболочки, вам понравится PowerShell!
Начните с Экскурсия по командной оболочке Microsoft (Ars Technica).
Когда вы сравниваете PowerShell с комбинацией Cygwin/Perl/Shell, имейте в виду, что PowerShell представляет только часть "Shell" этой комбинации.
Однако вы можете вызывать любую команду из PowerShell так же, как вы делаете из cmd.exe или Cygwin. Он не выполняет повторную реализацию указанных функций и, безусловно, не сопоставим с Perl.
Это "просто" оболочка, но упрощает программирование, обеспечивая удобный интерфейс для юниверса .Net.
Также имейте в виду, что PowerShell требует WinXP, Srv2003 или выше, что может представлять проблему в зависимости от вашей ИТ-инфраструктуры.
Update:
Я понятия не имел, какие философские дебаты мой ответ искроет.
Я отправил свой ответ в контексте вопроса: сравните PowerShell с Cygwin и Perl и bash.
PowerShell - это оболочка, поскольку он не делает синтаксической разницы между встроенными командами, командами, пользовательскими функциями и внешними командами (.exe,.bat,.cmd). Только использование методов .Net отличается добавлением пространства имен или объекта в вызове.
Его программируемость основывается на .Net framework, а не на чем-то специфичном для языка PowerShell.
Я бы сказал, что PowerShell - это "язык сценариев", как только Bugzilla или MediaWiki реализованы как сценарии PowerShell, запущенные на веб-сервере;)
До тех пор, наслаждайтесь сравнения.
Как мои недавние эксперименты привели меня в глубины вызовов Powershell и .NET, я должен сказать, что Powershell может заменить Cygwin и Unix shell. Я не уверен в Perl, но поскольку и Powershell, и Perl являются Turing законченными как языки программирования, я даю это как да для замены Perl тоже. Одна вещь, которую Powershell имеет выше Cygwin и обычного bash под * nix, - это возможность выполнять изолированные вызовы DLL, манипулировать операционной системой с помощью прямых вызовов API, методов WMI и даже COM-объектов. Как насчет запуска IE через код, а затем делать все, что хотите, с его отображаемым документом, эффективно эмулируя фоновый сервер для веб-сервера? Как собирать данные с SQL-серверов и других поставщиков данных, анализировать их и экспортировать как CSV, почтовые сообщения, текст и фактически любые существующие и несуществующие форматы файлов? (Разумеется, с надлежащими навыками создания достоверного файла из полученных данных, но CSV легко доступны). И есть дополнительная безопасность, доступная через подписанные командлеты и сценарии, групповые политики и политики выполнения, которые предотвращают запуск вредоносных кодов на вашем компьютере. даже если вы запускаете их как администратор.
О том, какие команды реализованы - ответ Ричарда перечисляет их и способность Powershell имитировать их функциональность уже.
О том, сильна ли Powershell, чтобы гарантировать переход - это больше зависит от личных предпочтений, хотя, поскольку все больше и больше услуг Windows предоставляют командлеты Powershell для их контроля, а использование Powershell с этими сервисами не является препятствием. (Сервер Hyper-V является основной такой услугой, он также предоставляет возможность делать больше с командлетами Powershell, чем с GUI!)
Вероятно, этот ответ задерживается на пять лет, но все же, если кто-то выполняет административные задачи или общие сценарии различных вещей в Windows, они должны определенно попытаться использовать Powershell для своих целей.
TL; DR - я не ненавижу Windows или Powershell. Я просто ничего не могу сделать в Windows или Powershell.
Я лично до сих пор считаю, что в лучшем случае это не так.
~/
, за исключением некоторых @environment://somejibberish/%user_home%
NTFS по-прежнему беспорядок и, похоже, всегда будет, удача навигации.
Интерфейс cmd-esque, динозавр cmd.exe по-прежнему отображается в Powershell, edit->mark
по-прежнему является единственным способом копирования информации и копирования только в виде прямоугольных блоков видимого пространства на терминале. и edit->paste
остается единственным способом вставки строк в терминал.
Картина синего цвета не делает ее более привлекательной. Я не против разработчиков MS, имеющих вкус в цвете, хотя.
Windows всегда открывается в верхнем левом углу экрана. Для тех, кто использует вертикальные панели задач, это невероятно раздражает, особенно учитывая, что панель задач Windows будет охватывать единственный угол окна, который дает доступ к копированию/вставке функциональность.
Я не могу много говорить о том, что включает окна инструментов. Будучи тем, что есть целый набор свободно распространяемых, свободно лицензированных инструментов cli и корабли powershell, насколько мне известно, ни одно из них не является полным разочарованием.
wget
воспринимает, казалось бы, несравнимые аргументы gnu wget, благодаря проблеску надежды, бесполезно-бесполезно.&&
не обрабатывается, делая простейшую из условных команд, а не ничего.Я не знаю, я сделал это, я действительно это сделал; Я все еще пытаюсь дать ему шанс в надежде, что в следующий раз, когда я его открою, он будет менее бесполезным. Я ничего не могу сделать в PowerShell, и я могу смиренно делать с реальным проектом, чтобы принести инструменты gnu в Windows.
MySysGit дает мне подсказку cmd.exe динозавра с помощью нескольких инструментов gnu, которые все еще очень неудобны, но, наконец, завершение работы заканчивается. и команда git будет запущена в gitBash
Mintty для MySysGit предоставляет интерфейс Cygwin поверх среды mysysgit, делая копию и вставляя вещь. (выберите для копирования (мышь), shift + ins, чтобы вставить, как современный...), однако в Mintty нарушаются такие вещи, как git push
.
Я не хочу говорить, но я все еще вижу огромные проблемы с удобством использования в командной строке на окнах даже с такими инструментами, как Cygwin.
P.S. Просто заставьте что-то сделать в powershell, don't сделать его годным к употреблению, удобство использования глубже, чем способность, и это то, на что я склонен сосредоточиться, пытаясь использовать продукт в качестве потребителя.
.
или [
для доступа к свойству или индексу, поэтому он не может просто добавить разделитель пути в конце. Какой именно PowerShell wget? Какой PowerShell POSIX? Он не пытается перенести инструменты gnu в Windows или быть совместимым с bash.
Командлеты в powershell очень приятны и работают надежно. Их объектно-ориентированность мне очень нравится, так как я разработчик java/С#, но это совсем не полный набор. Поскольку он объектно ориентирован, он пропустил много текстового потока набора инструментов POSIX (awk
и sed
), чтобы назвать несколько).
Лучший ответ, который я нашел для дилеммы любви к методам ОО и любви к зрелости в инструментах POSIX, - это использовать оба! Один большой аспект Powershell заключается в том, что он отлично подходит для работы с объектами трубопроводов для стандартных потоков. Powershell по умолчанию использует конвейер объекта для транспортировки своих объектов. Это не стандартные потоки (стандартная ошибка, стандартная ошибка и стандарт). Когда Powershell должен передать вывод стандартного процесса, который не имеет конвейера объекта, он сначала преобразует объекты в текстовый поток. Поскольку он делает это так хорошо, Powershell отлично подходит для размещения POSIX-инструментов!
Лучший набор инструментов POSIX GnuWin32. Для установки требуется более 5 секунд, но это стоит того, и, насколько я могу судить, он не изменяет вашу систему (реестр, папки c:\windows\*
и т.д.), За исключением копирования файлов в указанные вами каталоги, Это очень приятно, потому что, если вы поместите инструменты в общий каталог, многие люди могут получить к ним доступ одновременно.
Загрузите и выполните exe (это из сайта SourceForge), указывая его на подходящий каталог (я буду использовать c:\bin
). Он создаст каталог GetGnuWin32
, в котором вы запустите download.bat
, затем install.bat
(без параметров), после чего появится каталог c:\bin\GetGnuWin32\gnuwin32\bin
, который является наиболее полезной папкой, которая когда-либо существовала на Windows. Добавьте этот каталог на свой путь, и вы готовы к работе.
Почему бы не использовать оба? Вызовите скрипты PowerShell в Cygwin так же, как и любые другие интерпретируемые скрипты, такие как perl и т.д.
Я делаю это достаточно, чтобы написать https://bitbucket.org/jbianchi/powershell для обертки bash для вызова powershell.exe в Cygwin. Может использоваться как Shebang в качестве первой строки файла powershell.exe.ps1 script (поскольку powershell также использует "#" в качестве комментария). См. https://bitbucket.org/jbianchi/powershell/wiki/Home для примеров
Я не видел, что Powershell действительно вылетел, по крайней мере, пока. Поэтому, возможно, не стоит изучать его, если только те, кто в вашей команде уже этого не знают.
Для вашего затруднительного положения вам может быть лучше с языком сценариев, который другие могут удержать, Perl, как вы упомянули, или другими, такими как Ruby или Python.
Я думаю, что многое зависит от того, что вам нужно делать. Лично я использовал Python для своих личных скриптов, но знаю, когда начинаю писать то, что я никогда не смогу передать, поэтому стараюсь не делать ничего слишком революционного.
В нескольких строках Cygwin и Powershell - это разные инструменты, однако, если у вас установлена Cygwin, вы можете запускать исполняемые файлы Cygwin в сеансе Powershell. Я настолько привык к Powershell, что теперь я больше не использую grep, sort, awk и т.д. В Powershell есть довольно много встроенных альтернатив, и если нет, вы можете найти там командлет.
Основным инструментом, который я использую, является ssh.exe, но в сеансе Powershell.
Отлично работает.
PowerShell является очень мощным, более мощным, чем стандартные встроенные модули Unix (но только потому, что он включает в себя большую часть функциональности, обычно выгружаемой в подпрограммы). Также подумайте, что вы можете писать апплеты на любом языке .NET, включая IronPython, IronRuby, PerlNet и т.д., Или вы можете просто называть свои команды cygwin из PowerShell, игнорируя все дополнительные функции, и он будет работать аналогично bash, korn, или что-то еще...
Вы также можете попробовать запустить сценарии Bash на окнах, используя BashWin at https://github.com/skanga/BashWin
Я нашел, что программирование PowerShell не стоит усилий.
У меня есть многолетний опыт работы с shell-скриптами под Unix, но мне очень трудно было что-то сделать с PowerShell.
Кажется, что многие функции требуют от вас опроса интерфейса управления Windows и выдачи SQL-подобных команд для получения необходимой вам информации.
Например, я хотел написать script, чтобы удалить все файлы с определенным суффиксом из дерева каталогов. В Unix это было бы просто...
find . -name \*.xyz -exec rm {} \;
Через пару часов обманывают Scripting.FileSystemObject
и WScript.Shell
и выдают "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" и диск и "И путь =" и searchFolder и "", я наконец дал и запустили команду Windows Explorer Поиск и просто сделайте это вручную. Вероятно, есть способ сделать то, что я хотел, но я не видел ничего очевидного, и все примеры на сайте MSDN были настолько тривиальны, что были бесполезны.
EDIT Хех, конечно, как только я это написал, я еще несколько раз подсунул и обнаружил, что мне не хватало: опция -recurse
для команды remove-item неисправна (отображается, если вы используете get-help remove-item -detailed
).
Я пытался "remove-item -filter" *.xyz "-recurse", и он не работал, поэтому я отказался от него.
Оказывается, вам нужно использовать get-childitem -filter '*.xyz' -recurse | remove-item