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

grep

и -match работа оператора с regexes. Также вы можете напрямую использовать .Поддержка regex сети для более продвинутых функций.

вроде

Sort-Object более мощный (чем я помню, для *Nix-ы sort). Разрешение многоуровневой сортировки по произвольным выражениям. Здесь помогает обслуживание базового типа PSH; например, a DateTime свойство будет отсортировано как DateTime без необходимо обеспечить форматирование в сортируемый формат.

uniq

Select-Object -Unique

Perl (насколько близко PowerShell подходит к возможностям Perl?)

С точки зрения ширины Perl конкретных библиотек поддержки домена: нигде близко (пока).

для общего программирования PSH, безусловно, более сплоченный и последовательный, и легче расширить. Один пробел для текста munging является чем-то эквивалентным чтобы в Perl .. оператора.

на awk

прошло достаточно много времени с момента использования awk (должно быть >18 лет, так как позже я просто использовал perl), поэтому не могу комментировать.

sed

[смотри выше]

file (команда, которая дает информацию о файле)

сила PSH здесь не так много того, что он может сделать с объектами файловой системы (и он получает полную информацию здесь, dir возвращает FileInfo или FolderInfo объекты по мере необходимости) - это вся модель поставщика.

вы можете обработать реестр, хранилище сертификатов, SQL Server, RSS-кэш IE и т. д. как пространство объектов, управляемое теми же командлетами, что и файловая система.

PSH, безусловно, путь вперед на Windows. MS сделали его частью своих требований к будущим продуктам non-home. Следовательно, богатая поддержка в Exchange, поддержка в SQL Server, это только собирается расширять.

недавним примером этого является TFS PowerToys. Многие операции клиента TFS выполняются без необходимости запуска tf.exe каждый раз (что требует нового подключения к серверу TFS и т. д.) и значительно легче затем дополнительно обрабатывать данные. А также предоставление широкого доступа ко всему API клиента TFS более подробно, чем в любом Team Explorer TF.исполняемый.

как кто - то, чья карьера сосредоточена на развитии Windows enterprise с 1997 по 2010 год, очевидным ответом будет Powershell по всем приведенным выше причинам (например, это часть корпоративной стратегии MS; она хорошо интегрируется с Windows/COM/.NET; и использование объектов вместо файлов обеспечивает "более богатую" модель кодирования). По этой причине я использовал и продвигал Powershell в течение последних 2 лет или около того, с явным убеждением, что я следовал " слову Законопроект."

однако, как прагматик, я больше не уверен, что Powershell-такой отличный ответ. Хотя это отличный инструмент для Windows и обеспечивает столь необходимый шаг к заполнению исторической дыры, которая является командной строкой окна, поскольку мы все наблюдаем, как MS захватывает потребительские вычисления, кажется все более вероятным, что MS имеет массивную битву впереди, чтобы сохранить ОС как важную для предприятия будущего.

действительно, учитывая, что я нахожу свою работу все более неоднородной среды, я нахожу гораздо более полезным использовать сценарии bash на данный момент, поскольку они не только работают на Linux, Solaris и Mac OS X, но и работают-с помощью Cygwin-на Windows.

поэтому, если вы верите в то, что будущее ОС коммодитизировано, а не монополизировано, тогда, похоже, имеет смысл выбрать стратегию гибкого инструмента разработки, которая держится подальше от проприетарных инструментов, где это возможно. Если, однако, вы видите, что в вашем будущем доминируют все-что-есть-Редмонд затем пойти на Powershell.

Я использовал немного PowerShell для автоматизации сценариев. Хотя очень приятно, что среда, похоже, была продумана намного больше, чем оболочки Unix, на практике использование объектов вместо текстовых потоков намного более неуклюже, и многие средства Unix, которые были разработаны за последние 30 лет, все еще отсутствуют.

Cygwin по-прежнему является моей средой сценариев для хостов Windows. Это, безусловно, превосходит альтернативы с точки зрения получения вещей сделанный.

много великих великих ответов, вот мой взгляд. PS готов, если вы готовы... Пример

grep ="Select-String-Pattern"

сортировка = "Сортировка"- "Объект"

uniq ="Get-Unique"

file =" Get-Item"

cat ="Get-Content"

Perl / Awk/Sed не являются командой, но утилиты, следовательно, трудно сравнить, но вы можете сделать почти все в В PowerShell.

Я только недавно начал заниматься PS С любой степенью серьезности. Хотя в течение последних семи лет я работал почти исключительно в среде на базе Windows, я пришел из фона Unix и постоянно пытаюсь "Unix-fy" мой опыт взаимодействия в Windows. Это, мягко говоря, расстраивает.

справедливо сравнивать PS Для что-то вроде Баш, tcsh или ЗШ так как утилиты, как grep, sed, на awk, найти etc. строго говоря, они не являются частью оболочки; однако они всегда будут частью любой среды Unix. Тем не менее, команда PS, как Select-String имеет очень похожую функцию на grep и is в комплекте как основной модуль в PS ... так что линии могут быть немного размыты.

Я думаю, что ключ дело культура, и тот факт, что соответствующие наборы инструментов будут воплощать их соответствующие культуры:

• Unix-это , (в общем, не Unicode) на основе текста культуры. Конфигурационные файлы почти исключительно текст файлы. Windows, с другой стороны, всегда была гораздо более структурирована в отношении форматов конфигурации-конфигурации, как правило, хранятся в собственных базах данных (например, Реестр Windows), которые требуют специализированных инструментов для их управления.

• административный интерфейс Unix (и, в течение многих лет, разработка) традиционно был командной строкой и виртуальным терминалом. Windows начиналась как GUI, и административные функции только недавно начали отходить отисключительно GUI-based. Мы можем ожидать, что опыт Unix в командной строке будет более богатым, более зрелым, учитывая значительное лидерство на PS, и мой опыт совпадает с этим. Об этом, по моему опыту:

  • административный опыт Unix ориентирован на то, чтобы сделать вещи легко сделать в минимальном количестве ключевых штрихов; это, вероятно, в результате исторической ситуации, когда необходимо администрировать сервер по медленному 9600-бодному коммутируемому соединению. Теперь PS имеет псевдонимы, которые идут долгий путь, чтобы обойти довольно многословный Глагол-Существительное стандарт, но узнать эти псевдонимы немного больно (кто-нибудь знает что-то лучше, чем: alias | where {$_.ResolvedCommandName -eq "<command>"}?).

    пример богатого способа манипулирования историей:

    iptables команды часто многословны и повторение их с небольшими различиями было бы болью, если бы не одна из многих аккуратных особенностей манипуляции историей, встроенной в Баш, поэтому вставка правила 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 оптимизирован для сенсорных машинисток; можно в значительной степени сделать все, не выходя из "домашней" позиции. Например, в Баш, используя Emacs привязки клавиш (да, Bash также поддерживает vi привязки), езда на велосипеде по истории делается с помощью Ctrl-P и Ctrl-N при перемещении в начало и конец строки выполняется с помощью Ctrl-A и Ctrl-E соответственно ... и это определенно не конец. Попробуйте даже самую простую навигацию в PS консоль без перемещения из положения "домой", и вы находитесь в беда.

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

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

Я никоим образом не очень опытный пользователь PowerShell, но небольшая его часть, с которой я столкнулся, произвела на меня большое впечатление. Вы можете связать встроенные командлеты вместе, чтобы сделать почти все, что вы могли бы сделать в командной строке Unix, и есть некоторые дополнительные преимущества для таких вещей, как экспорт в CSV, HTML-таблицы и для более глубоких типов заданий системного администратора. И если вам действительно нужно что-то типа sed, всегда UnixUtils или GnuWin32, который вы могли бы интегрировать с Powershell довольно легко.

как давний пользователь Unix, у меня, однако, были проблемы с привыканием к схеме именования команд, и я, конечно, выиграл бы от этого больше, если бы знал больше .Сеть.

поэтому, по сути, я говорю, что это стоит изучить, если только для Windows это не представляет проблемы.

Если вам нравятся сценарии оболочки, Вам понравится PowerShell!

начинаются экскурсия по командной консоли Microsoft (Ars Technica).

когда вы сравниваете PowerShell с комбинацией Cygwin / Perl / Shell, имейте в виду, что PowerShell представляет только часть "оболочки" этой комбинации.

однако вы можете вызвать любую команду из PowerShell так же, как и из cmd.exe или Cygwin. Это не повторно реализовать указанные функции, и это, конечно, не сравнимо с Perl.

Это" просто " оболочка, но это упрощает Программирование, предоставляя удобный интерфейс для .Net вселенная.

также имейте в виду, что PowerShell требует WinXP, Srv2003 или выше, что может создать проблему в зависимости от вашей ИТ-инфраструктуры.

обновление:

Я понятия не имел, какую философскую дискуссию вызовет мой ответ.

Я опубликовал свой ответ в контексте вопроса: сравните PowerShell с Cygwin и Perl и bash.

PowerShell-это оболочка, поскольку она не делает синтаксической разницы между встроенными командами, командлеты, пользовательские функции и внешние команды (.исполняемый. ,летучая мышь. ,УМК.) Только вызов .Net-методов отличается добавлением пространства имен или объекта в вызове.

его программируемость происходит от .Net framework, а не от чего-либо конкретного для "языка"PowerShell.

Я бы сказал, что считаю PowerShell "языком сценариев", как только Bugzilla или MediaWiki реализованы как сценарии PowerShell, запущенные на веб-сервере ;)

пока наслаждайтесь сравнения.

поскольку мои недавние эксперименты привели меня в глубины вызовов Powershell и .NET, я должен сказать, что Powershell can замените Cygwin и оболочку Unix. Я не уверен в 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, я просто не могу do что - нибудь в windows или Powershell.

Я лично все еще нахожу powershell в лучшем случае неутешительным.

• вкладка завершение путей к каталогу не соединяется, требуя, чтобы пользователь вводил разделитель путей после каждого завершения имени.
• я все еще чувствую, что windows даже не концепция пути или того, что такое путь, без доступного дома пользователя индикатор ~/ хватает @environment://somejibberish/%user_home%

• NTFS по-прежнему беспорядок и, казалось бы, всегда будет, удачи навигации.

• cmd-esque интерфейс, динозавр cmd.exe по-прежнему отображается в Powershell, edit->mark по-прежнему является единственным способом копирования информации и копирования только в виде прямоугольных блоков видимого терминального пространства. и edit->paste по-прежнему является единственным способом, чтобы вставить строки в терминал.

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

• Windows всегда открывается в верхнем левом углу экрана, для тех, кто использует вертикальные панели задач это невероятно раздражает, особенно учитывая, что панель задач windows будет охватывать единственный угол окна, который дает доступ к функции копирования/вставки.

Я не могу говорить много на основании инструментов windows включает в себя. Поскольку существует целый набор инструментов cli с открытым исходным кодом, свободно лицензированных, и powershell поставляется, насколько мне известно, ни один из них не является полным разочарованием.

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

командлеты в powershell очень хороши и работают надежно. Их объектно-ориентированность мне очень нравится, так как я разработчик java/C#, но это вовсе не полный набор. Поскольку он объектно-ориентированный, он пропустил много текстовый поток зрелость набора инструментов POSIX (awk и sed чтобы назвать несколько).

лучший ответ, который я нашел на дилемму любви к методам OO и любви к зрелости в инструментах POSIX, - это использовать оба! Один великий аспект Powershell заключается в том, что он отлично выполняет работу по конвейеризации объектов в стандартные потоки. Powershell по умолчанию использует конвейер объектов для транспортировки своих объектов. Это не стандартные потоки (standard out, standard error и standard in). Когда 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 действительно взлетел, по крайней мере, пока нет. Так что это может не стоить усилий, чтобы узнать его, если те, другие в вашей команде уже знают это.

для вашего затруднительного положения вам может быть лучше с языком сценариев, который другие могут получить позади, Perl, как вы упомянули, или другие, как Ruby или Python.

Я думаю, что много зависит от того, что вам нужно сделать. Лично я использую Python для своих личных скриптов, но я знайте, когда я начинаю писать что - то, я никогда не смогу передать это дальше-поэтому я стараюсь не делать ничего слишком революционного.

Почему бы не использовать оба? Вызовите сценарии PowerShell в Cygwin так же, как и любые другие интерпретируемые сценарии, такие как perl и т. д.

Я делаю это достаточно, чтобы я написал https://bitbucket.org/jbianchi/powershell для оболочки bash для вызова powershell.exe в Cygwin. Может использоваться как Shebang в качестве первой строки powershell.exe .сценарий ps1 (поскольку powershell также использует " # " в качестве комментария). Вижу https://bitbucket.org/jbianchi/powershell/wiki/Home примеры

PowerShell очень мощный, более мощный, чем стандартные встроенные оболочки Unix (но только потому, что он включает в себя большую часть функциональности, обычно выкладываются на подпрограммы). Кроме того, считайте, что вы можете писать апплеты на любом языке .NET, включая IronPython, IronRuby, PerlNet и т. д.. или вы можете просто вызвать свои команды cygwin из PowerShell, игнорируя все дополнительные функции, и он будет работать аналогично bash, korn или что-то еще...

в нескольких строках Cygwin и Powershell-это разные инструменты, однако если у Вас установлен Cygwin, вы можете запустить исполняемые файлы Cygwin в сеансе Powershell. Я так привык к Powershell, что теперь больше не использую grep, sort, awk и т. д. В Powershell есть довольно много встроенных альтернатив,и если нет, вы можете найти командлет.

основным инструментом, который я использую, является ssh.exe, но в сеансе Powershell.

работает отлично.

вы также можете попробовать запустить сценарии Bash в windows с помощью BashWin на https://github.com/skanga/BashWin

я обнаружил, что Программирование PowerShell не стоит усилий.

у меня есть несколько лет опыта работы со сценариями оболочки под Unix, но мне было чрезвычайно сложно что-либо сделать с PowerShell.

похоже, что многие функции требуют, чтобы вы опрашивали интерфейс управления Windows и выдавали SQL-подобные команды для получения необходимой вам информации.

например, я хотел написать скрипт удалить все файлы с суффикс из дерева каталогов. в Unix это было бы просто ...

find . -name \*.xyz -exec rm {} \;

после пары часов возиться с Scripting.FileSystemObject и WScript.Shell и выдав "SELECT * из Win32_ShortcutFile, где Drive = '"& drive & "'и Path = '" & searchFolder&"'", я, наконец, сдался и остановился на проводнике Windows Поиск и просто сделать это вручную. Вероятно, есть какой-то способ сделать то, что я хотел, но я не видел ничего очевидного и все примеры на сайте MSDN были настолько тривиальны, что были бесполезны.

редактировать-recurse опция команды remove-item неисправна (выявлено, если вы используете get-help remove-item -detailed).

Я пытался "удалить элемент-фильтр"* .xyz '- recurse", и он не работал, поэтому я отказался от него.

оказывается, вам нужно использовать get-childitem -filter '*.xyz' -recurse | remove-item