Чи готовий PowerShell замінити мою оболонку Cygwin у Windows? [зачинено]

Я обговорюю, чи варто вивчати PowerShell, чи просто дотримуватися скриптів Cygwin / Perl / скриптів оболонки Unix тощо.

Перевага PowerShell полягала б у тому, що сценарії могли легше використовувати товариші по команді, у яких немає Cygwin; однак я не знаю, чи справді я писав би такі сценарії загального призначення, чи люди навіть їх використовуватимуть.

Сценарій Unix є настільки потужним, чи PowerShell наблизився досить близько, щоб вимагати перемикання?

Ось деякі конкретні речі (або їх еквіваленти), які я шукав би в PowerShell:

• греп
• сортувати
• uniq
• Perl (наскільки близько PowerShell підходить до можливостей Perl?)
• AWK
• sed
• файл (команда, яка дає інформацію про файл)
• тощо.

Інструменти - це лише інструменти.
Вони допомагають чи ні.
Вам потрібна допомога чи ні.

Якщо ви знаєте, що 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 доступним на всіх платформах, Windows XP та вище. Іншими словами - ваші інвестиції в навчання будуть застосовні до дуже великої кількості машин / середовищ.

Останній коментар. Якщо / коли ви почнете вивчати PowerShell, я думаю, ви будете дуже щасливі. Значна частина дизайну сильно впливає на наш фон Unix, тому, якщо ми зовсім інші, ви підберете його дуже швидко (після того, як перестанете говорити, що це не Unix :-)).

Ми знаємо, що люди мають дуже обмежений бюджет на навчання - саме тому ми дуже жорсткі щодо послідовності. Ви збираєтесь щось навчитися, а потім будете використовувати це знову і знову і знову.

Експериментуйте! Насолоджуйтесь! Займайся!

греп

Select-Stringcmdlet і -matchоператор працюють з регулярними виразами. Також ви можете безпосередньо скористатися підтримкою регулярних виразів .NET для більш розширеної функціональності.

сортувати

Sort-Objectє більш потужним (ніж я пам'ятаю * nix's sort). Дозволення багаторівневої сортування на довільних виразах. Тут допомагає підтримка базового типу PowerShell; наприклад, DateTimeвластивість буде відсортовано як DateTimeбез необхідності забезпечення форматування у форматі сортування.

uniq

Select-Object -Unique

Perl (наскільки близько PowerShell наближається до можливостей Perl?)

З точки зору широти Perl, орієнтованої на доменні бібліотеки підтримки: ніде близько (поки що).

Що стосується загального програмування, PowerShell, безумовно, є більш згуртованим та послідовним та легшим для розширення. Один проміжок для розміщення тексту - це щось еквівалентне ..оператору Perl .

AWK

З моменту використання AWK минуло досить довго (повинно бути> 18 років, оскільки пізніше я просто використовував Perl), тому не можу коментувати.

sed

[Дивись вище]

файл (команда, яка дає інформацію про файл)

Сила PowerShell тут не стільки з того, що вона може зробити з об'єктами файлової системи (і тут вона отримує повну інформацію, dirповернення FileInfoабо FolderInfoоб'єкти, як це доречно), це вся модель провайдера.

Ви можете розглядати реєстр, сховище сертифікатів, SQL Server, RSS-кеш Internet Explorer тощо, як об'єктний простір, який переміщується тими ж командлетами, що і файлова система.

PowerShell - це безперечно шлях у Windows. Microsoft зробила це частиною своїх вимог щодо майбутніх неприбуткових продуктів. Отже, велика підтримка в Exchange, підтримка в SQL Server. Це лише розшириться.

Недавній приклад цього - TFS PowerToys. Багато операцій з клієнтом TFS виконуються без необхідності запуску tf.exe кожного разу (для чого потрібне нове підключення до сервера TFS тощо), і це значно простіше для подальшої обробки даних. А також дозволяє широкий доступ до всього API клієнтського TFS до більш детальної інформації, ніж експонований у будь-якому Team Explorer TF.exe.

Як хтось, чия кар'єра була зосереджена на розробці Windows в період з 1997 по 2010 рік, очевидною відповіддю буде PowerShell з усіх поважних причин (наприклад, це частина корпоративної стратегії Microsoft; вона добре інтегрується з Windows / COM / .NET; і використання об'єктів замість файлів передбачає "багатшу" модель кодування). З цієї причини я використовував і просував PowerShell протягом останніх двох років або близько того, з вираженою переконанням, що я слідував за «Словом Білла».

Однак, як прагматик, я більше не впевнений, що PowerShell є такою чудовою відповіддю. Хоча це чудовий інструмент Windows і забезпечує дуже потрібний крок до заповнення історичної діри, яка є командним рядком Window, оскільки ми всі спостерігаємо за тим, як Microsoft впорається з споживчими комп'ютерними ковзаннями. важливі для підприємства майбутнього.

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

Тож якщо ви переконаєтесь у тому, що майбутнє ОС є комодитизованим, а не монополізованим, то, мабуть, має сенс обратись до спритної стратегії інструментів розвитку, яка тримається подалі від власних інструментів, де це можливо. Якщо ви бачите, що у вашому майбутньому домінує все-що-є-Редмонд, тоді займіться PowerShell.

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

Cygwin все ще є моїм сценарієм для вибору хостів Windows. Це, безумовно, перемагає альтернативи з точки зору того, що можна зробити.

Тут є багато чудових чудових відповідей, і ось моя думка. PowerShell готовий, якщо ви ... Приклади:

grep = " Select-String -Pattern "

sort = "Сортувати-об'єкт"

uniq = " Get-Unique "

file = " Отримати елемент "

cat = " Отримати вміст "

Perl / AWK / Sed - це не команди, а утиліти, отже, важко порівняти, але ви можете зробити майже все в PowerShell.

Я тільки нещодавно почав дайвінг в PowerShell з будь-якою серйозністю. Хоча протягом останніх семи років я працював у майже виключно Windows-середовищі, я походжу з фонових зображень Unix і постійно намагаюся "Unix-fy" переглядати свій досвід взаємодії в Windows. Найменш засмучуюче.

Справедливо лише порівняти PowerShell з чимось на зразок Bash , tcsh або zsh, оскільки утиліти, такі як grep , sed , awk , find тощо, не є, строго кажучи, частиною оболонки; Однак вони завжди будуть частиною будь-якого середовища Unix. Тим НЕ менше, команда PowerShell , як Select-String має дуже схожу функцію Grep і в комплекті в якості основного модуля в PowerShell ... так що лінії можуть бути дещо розмитими.

Я думаю, що головне - це культура , а також те, що відповідні набори інструментів втілюють їхні відповідні культури:

• Unix - це файлова культура (взагалі не Unicode), заснована на тексті . Файли конфігурації - це майже виключно текстові файли. З іншого боку, Windows завжди була набагато структурованішою щодо форматів конфігурації - конфігурації, як правило, зберігаються у власних базах даних (наприклад, реєстрі Windows), які потребують спеціалізованих інструментів для управління ними.

• Інтерфейс адміністратора Unix (і вже багато років розробка) традиційно є командним рядком та віртуальним терміналом. Windows почав функціонувати як графічний інтерфейс, а адміністративні функції лише нещодавно почали відходити від виключно на основі GUI. Ми можемо очікувати, що досвід команд Unix у командному рядку буде багатшим, зрілішим, враховуючи значні переваги, які він має у PowerShell, і мій досвід відповідає цьому. З цього приводу, на мій досвід:

  • Управлінський досвід Unix орієнтований на те, щоб зробити речі простіми в мінімальній кількості ключових ударів; це, мабуть, є наслідком історичної ситуації з необхідністю адмініструвати сервер через повільний комутаційний зв'язок 9600 бод. Тепер у PowerShell є псевдоніми, які проходять довгий шлях, щоб обійти досить багатослівний стандарт дієслова-іменника , але знайомство з цими псевдонімами - це біль (хтось знає про щось краще, ніж 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відповідно ... і це , безумовно , не закінчується. Спробуйте навіть найпростішу навігацію в консолі PowerShell, не рухаючись з домашнього положення, і ви потрапили в біду.

  • Прості речі, такі як багатостороннє підказка (не менше ) на Unix, здається, не доступні у програмі PowerShell, що трохи неприємно, і багатий досвід редактора також не існує. Звичайно, завжди можна завантажити сторонні інструменти, які заповнять ці прогалини, але, безумовно, було б непогано, якби ці речі були просто «там», як вони є у будь-якому ароматі Unix.

• Культура Windows, принаймні з точки зору системного API, значною мірою визначається підтримуючими структурами, а саме: COM та .NET , обидві з яких є високоструктурованими та об'єктно-орієнтованими. З іншого боку, доступ до API API Unix традиційно здійснюється через файловий інтерфейс ( /devі /proc) або (не об'єктно-орієнтований) виклик бібліотеки у стилі C. Тож не дивно, що сценарійний досвід відповідає їх парадигмам ОС. PowerShell за своєю природою структурований (все є об'єктом) та Bash -and-friends на основі файлів. Структурований API, який є в розпорядженні програміста PowerShell, є величезним (по суті відповідає перевазі існуючого набору стандартних інтерфейсів COM та .NET).

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

Я не є дуже досвідченим користувачем PowerShell будь-якими способами, але трохи цього, що я піддався, вразило мене дуже багато. Ви можете зв'язати вбудовані командлети разом, щоб зробити майже все, що можна зробити в підказці Unix, і є додаткова користь для таких дій, як експорт до CSV, HTML таблиць, а також для більш поглиблених типів системного адміністрування .

І якщо вам дійсно потрібно щось на зразок sed , завжди є UnixUtils або GnuWin32 , які ви могли легко інтегрувати з PowerShell.

Як давній користувач Unix, у мене були певні проблеми з звиканням до схеми імен команд, і я, звичайно, отримав би більше користі від цього, якби знав більше .NET.

Отже, по суті, я кажу, що це варто вивчити, якщо це не тільки для Windows.

Якщо вам подобається сценарій оболонок, вам сподобається PowerShell!

Почніть з екскурсії по командній оболонці Microsoft (Ars Technica).

Оскільки мої останні експерименти привели мене до глибини викликів PowerShell і .NET, я повинен сказати, що PowerShell може замінити оболонки Cygwin та Unix.

Я не впевнений у Perl, але оскільки і PowerShell, і Perl є Turing завершеними як мови програмування, я даю це як так і заміні Perl.

Одне, що PowerShell має вище Cygwin та звичайного Bash під * nix, - це його здатність виконувати пісочні виклики DLL, маніпулюючи операційною системою за допомогою прямих дзвінків API, методів WMI та навіть об'єктів COM. Як щодо запуску Internet Explorer за допомогою коду, а потім робити все, що завгодно, з його відображеним документом, ефективно емулюючи бек-енд для веб-сервера?

Як щодо збирання даних із SQL-серверів та інших постачальників даних, аналізує їх та експортує у вигляді CSV, поштових повідомлень, тексту та власне будь-якого типу існуючих та неіснуючих форматів файлів? (З належними навичками створення дійсного файлу з отриманих даних, звичайно, але CSV легко доступні).

А ще є додаткова безпека за допомогою підписаних командлетів та сценаріїв, групових політик та політик виконання, які запобігають запуску шкідливого коду у вашій системі, навіть якщо ви запускаєте їх як адміністратор.

Про те, які команди реалізовані - відповідь Річарда перераховує їх та можливість PowerShell емуляції їх функціональності вже.

Про те, чи сильно PowerShell вимагає переключення - це більше питання особистої переваги, хоча оскільки все більше служб Windows надають командлети PowerShell для управління ними, не використовуючи PowerShell для цих служб, вважається перешкодою. (Сервер Hyper-V є основним таким сервісом, і він також надає можливість робити більше з командлетами PowerShell, ніж з графічним інтерфейсом!)

Можливо, ця відповідь запізнюється на п'ять років, але все ж, якщо хтось виконує адміністративні завдання або загальні сценарії різного матеріалу в Windows, він обов'язково повинен спробувати використати PowerShell для своїх цілей.

Порівнюючи PowerShell із комбінацією Cygwin / Perl / Shell, майте на увазі, що PowerShell являє собою лише частину "Shell" цієї комбінації.

Однак ви можете викликати будь-яку команду з PowerShell так само, як і в cmd.exe або Cygwin. Він не повторно реалізує зазначені функції, і це, звичайно, не можна порівняти з Perl.

Це "просто" оболонка, але це спрощує програмування, забезпечуючи зручний інтерфейс до всесвіту .NET.

Також пам’ятайте, що PowerShell потребує Windows XP, Windows Server 2003 або новішої версії, що може спричинити проблеми залежно від вашої ІТ-інфраструктури.

Оновлення:

Я не мав уявлення про те, які філософські дебати будуть викликати мою відповідь.

Я розмістив свою відповідь у контексті запитання: Порівняйте PowerShell з Cygwin та Perl і Bash.

PowerShell - це оболонка, оскільки вона не має синтаксичної різниці між вбудованими командами, командлетами, функціями користувача та зовнішніми командами (.exe, .bat, .cmd). Тільки виклик методів .NET відрізняється додаванням простору імен або об'єкта у виклик.

Її програмованість випливає з .NET рамки, а не з нічого конкретного для мови PowerShell.

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

До цього часу насолоджуйтесь порівняннями .

Команди в PowerShell дуже приємні та працюють надійно. Їх об'єктно-орієнтована цінність мені подобається, оскільки я розробник Java / C #, але це зовсім не повний набір. Оскільки він орієнтований на об'єкт, він пропускається на багато зрілості текстового потоку набору інструментів POSIX ( awkіsed назвати декілька).

Найкраща відповідь, яку я знайшов на дилему любити методики OO та любити зрілість в інструментах 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. Додайте цей каталог до свого шляху, і ви готові йти.

TL; DR - я не ненавиджу Windows або PowerShell. Я просто не можу нічого зробити в Windows чи PowerShell.

Я особисто все ще вважаю, що PowerShell в кращому випадку переживає перевагу.

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

• NTFS все ще безлад, і, здавалося б, завжди буде. Успіхів у навігації.

• Інтерфейс cmd-esque, Динозавр cmd.exe все ще видно в PowerShell, Редагувати → Позначити як і раніше єдиний спосіб копіювання інформації та копіювання лише у вигляді прямокутних блоків видимого кінцевого простору. та Редагувати → Позначити як єдиний спосіб вставити рядки в термінал.

• Фарбування синім кольором не робить його більш привабливим. Я не проти, щоб розробники Microsoft мали смак у кольорі.

• Windows завжди відкривається у верхньому лівому куті екрана. Для тих, хто використовує вертикальні панелі завдань, це надзвичайно дратує, особливо враховуючи, що панель завдань Windows буде охоплювати єдиний кут вікна, який надає доступ до функцій копіювання / вставки.

Я не можу багато говорити на основі засобів, включених у Windows. Оскільки існує цілий набір інструментів CLI з відкритим кодом, вільно ліцензовані, і PowerShell поставляється, наскільки мені відомо, жоден з них не є цілком розчаруванням.

• PowerShell wgetприймає, здавалося б, незрівнянні аргументи до віджету GNU. Спасибі, проблиск надії портативно-марний.
• PowerShell POSIX не сумісний з Bash, особливо з &&оператором не обробляється, що робить найпростішою умовною командою слідування за нею.

Я не знаю людини; Я дав йому постріл, я справді зробив; Я все ще намагаюся дати йому постріл, сподіваючись, що наступного разу, коли я його відкрию, це стане менш марним. Я нічого не можу зробити в PowerShell, і я навряд чи можу зробити справжній проект із залучення інструментів GNU до Windows.

MySysGit дає мені динозавр cmd.exe підказку з парою інструментів GNU, і це все ще дуже непохитно, але нарешті завершення шляху працює. І команда Git запуститься в Git Bash.

Mintty для MySysGit надає інтерфейс Cygwin над середовищем mysysgit, роблячи копіювати та вставляти річ (виберіть для копіювання (миші), Shift+ Insдля вставки, як сучасне ...). Однак такі речі, якgit push Мінтті, зламані.

Я не хочу рентувати, але я все ще бачу величезні проблеми із зручністю використання командного рядка в Windows, навіть за допомогою таких інструментів, як Cygwin.

PS: Тому що щось можна зробити в PowerShell, це не робить його корисним . Практичність використання глибша, ніж здатність, і це те, на що я схильний зосереджуватися, намагаючись використовувати продукт як споживача.

Я не бачив, щоб PowerShell справді знявся, принаймні, поки що. Тому, можливо, не варто докладати зусиль, щоб навчитися цьому, якщо тільки інші з вашої команди вже не знають цього.

Для вашого загрози вам може бути краще мови сценаріїв, якою можуть відступити інші, Perl, як ви згадали, або інших, як Ruby або Python.

Я думаю, що багато чого залежить від того, що вам потрібно зробити. Особисто я використовував Python для власних особистих сценаріїв, але знаю, коли я починаю щось писати, що ніколи не зможу передати це - тому намагаюся не робити нічого надто революційного.

Чому б не використовувати обидва? Викликайте сценарії PowerShell в Cygwin так само, як і будь-які інші інтерпретовані сценарії, такі як Perl тощо.

Я цього роблю досить, щоб написав https://bitbucket.org/jbianchi/powershell для обгортки Bash, щоб зателефонувати powershell.exe в Cygwin. Він може бути використаний як шебанг як перший рядок сценарію powershell.exe .ps1 (оскільки PowerShell також використовує "#" в якості коментаря). Див. Https://bitbucket.org/jbianchi/powershell/wiki/Home для прикладів

У декількох рядках Cygwin та PowerShell є різними інструментами, проте якщо у вас встановлений Cygwin, ви можете запустити виконувані файли Cygwin протягом сеансу PowerShell. Я настільки звик до PowerShell, що зараз я більше не використовую grep, сортування, awk тощо. В PowerShell є вбудовані альтернативи, і якщо ні, ви не можете знайти командлет там.

Основним інструментом, яким я користуюсь, є ssh.exe, але в межах сеансу PowerShell.

Це чудово працює.

Я виявив, що програмування PowerShell не варте зусиль.

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

Схоже, що багато функцій вимагають допитати інтерфейс управління Windows і видавати команди, подібні SQL, щоб отримати необхідну інформацію.

Наприклад, я хотів написати скрипт для видалення всіх файлів із певним суфіксом із дерева каталогу. У Unix це було б просто ...

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

Через пару годин поспілкуючись із Scripting.FileSystemObjectта WScript.Shellвидаючи "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", я нарешті відмовився і погодився на команду пошуку Windows Explorer і просто зробіть це вручну. Напевно, є якийсь спосіб зробити те, що я хотів, але я не побачив нічого очевидного, і всі приклади на сайті MSDN були настільки банальними, що були нікчемними.

EDIT Heh, звичайно, як тільки я написав це, я поцікавився ще деяким і виявив те, чого я пропустив: -recurseопція для команди delete element є помилковою (виявляється, якщо ви використовуєтеget-help remove-item -detailed ).

Я намагався "delete-item -filter '* .xyz' -recurse", і він не працював, тому я відмовився від цього.

Виявляється, потрібно використовувати get-childitem -filter '*.xyz' -recurse | remove-item

Ви також можете спробувати запустити сценарії Bash у Windows за допомогою BashWin за адресою https://github.com/skanga/BashWin .

PowerShell є дуже потужним, потужнішим, ніж стандартні вбудовані оболонки Unix (але лише тому, що він включає в себе більшу частину функціональності, звичайно виділеного для підпрограм). Також врахуйте, що ви можете писати аплети будь-якою мовою .NET, включаючи IronPython , IronRuby , PerlNet тощо. Або просто можете викликати свої команди Cygwin з PowerShell, ігноруючи всю додаткову функціональність, і вона буде працювати аналогічно Bash, KornShell , чи що завгодно ...