Готов ли PowerShell заменить мою оболочку Cygwin в Windows?

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 - это основанная на файлах (в общем, не Unicode) текстовая культура. Файлы конфигурации - это почти исключительно текстовые файлы. Windows, с другой стороны, всегда была гораздо более структурирована в отношении форматов конфигурации - конфигурации обычно хранятся в запатентованных базах данных (например, в реестре Windows), для которых требуются специализированные инструменты для их управления.

• Административный (и на протяжении многих лет) интерфейс 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, не перемещаясь из исходной позиции, и у вас проблемы.

  • Простые вещи, такие как универсальный пейджинг (ala less) в Unix, по-видимому, не доступны из-за коробки в PS, что немного разочарование, а богатый опыт редактора тоже не существует. Конечно, всегда можно скачать сторонние инструменты, которые будут заполнять эти пробелы, но было бы неплохо, если бы эти вещи были просто "там", как будто они в значительной степени отличаются от Unix.
• Культура Windows, по крайней мере, с точки зрения системного API, во многом зависит от поддерживающих фреймворков, а именно: COM и .NET, оба из которых структурированных и объектных. С другой стороны, доступ к Unix API традиционно осуществляется через интерфейс библиотеки (/dev и /proc) или (не объектно-ориентированный) вызов библиотеки C-стиля. Неудивительно, что опыт сценариев соответствует их соответствующим парадигмам ОС. PSпо своей природе структурирован (все - объект) и Bash -и-друзья на основе файлов. Структурированный API, который находится в распоряжении программиста PS, обширен (в основном, соответствует обширности существующего набора стандартных интерфейсов COM и .NET).

Короче говоря, хотя возможности сценариев PS, возможно, более мощные, чем Bash (особенно если вы рассматриваете доступность .NET BCL), интерактивный опыт значительно слабее, особенно если вы используете его с полностью ориентированной на клавиатуру консольной точки зрения (как и у многих Unix-головок).

Много замечательных ответов, вот мой прием. PS готов, если вы... Пример

grep = "Select-String -Pattern"

sort = "Sort-Object"

uniq = "Get-Unique"

file = "Get-Item"

cat = "Get-Content"

Perl/Awk/Sed - это не команда, но утилиты, следовательно, трудно сравнивать, но вы можете делать почти все в Powershell.

Я не очень опытный пользователь 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, насколько мне известно, ни одно из них не является полным разочарованием.

• powershell wget воспринимает, казалось бы, несравнимые аргументы gnu wget, благодаря проблеску надежды, бесполезно-бесполезно.
• powershell posix не совместим с bash, в частности, оператор && не обрабатывается, делая простейшую из условных команд, а не ничего.

Я не знаю, я сделал это, я действительно это сделал; Я все еще пытаюсь дать ему шанс в надежде, что в следующий раз, когда я его открою, он будет менее бесполезным. Я ничего не могу сделать в 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 очень приятны и работают надежно. Их объектно-ориентированность мне очень нравится, так как я разработчик java/С#, но это совсем не полный набор. Поскольку он объектно ориентирован, он пропустил много текстового потока набора инструментов POSIX (awk и sed), чтобы назвать несколько).

Лучший ответ, который я нашел для дилеммы любви к методам ОО и любви к зрелости в инструментах POSIX, - это использовать оба! Один большой аспект Powershell заключается в том, что он отлично подходит для работы с объектами трубопроводов для стандартных потоков. Powershell по умолчанию использует конвейер объекта для транспортировки своих объектов. Это не стандартные потоки (стандартная ошибка, стандартная ошибка и стандарт). Когда Powershell должен передать вывод стандартного процесса, который не имеет конвейера объекта, он сначала преобразует объекты в текстовый поток. Поскольку он делает это так хорошо, Powershell отлично подходит для размещения POSIX-инструментов!

Лучший набор инструментов POSIX GnuWin32. Для установки требуется более 5 секунд, но это стоит того, и, насколько я могу судить, он не изменяет вашу систему (реестр, папки c:\windows\* и т.д.), За исключением копирования файлов в указанные вами каталоги, Это очень приятно, потому что, если вы поместите инструменты в общий каталог, многие люди могут получить к ним доступ одновременно.

Инструкции по установке GnuWin32

Загрузите и выполните 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