O PowerShell está pronto para substituir meu shell Cygwin no Windows? [fechadas]

Estou debatendo se devo aprender o PowerShell, ou ficar com os scripts Cygwin / Perl / shell scripts Unix, etc.

O benefício do PowerShell seria que os scripts pudessem ser mais facilmente usados ​​por colegas de equipe que não possuem Cygwin; no entanto, não sei se realmente escreveria muitos scripts de uso geral ou se as pessoas os usariam.

O script Unix é tão poderoso que o PowerShell chega perto o suficiente para garantir a troca?

Aqui estão algumas das coisas específicas (ou equivalentes) que eu procuraria no PowerShell:

• grep
• ordenar
• uniq
• Perl (a que distância o PowerShell chega dos recursos do Perl?)
• AWK
• sed
• file (o comando que fornece informações sobre o arquivo)
• etc.

Ferramentas são apenas ferramentas.
Eles ajudam ou não.
Você precisa de ajuda ou não.

Se você conhece o Unix e essas ferramentas fazem o que você precisa no Windows - você é um cara feliz e não precisa aprender o PowerShell (a menos que queira explorar).

Minha intenção original era incluir um conjunto de ferramentas Unix no Windows e acabar com ele (vários de nós na equipe têm profundos conhecimentos de Unix e uma dose saudável de respeito por essa comunidade).

O que eu descobri foi que isso realmente não ajudou muito. A razão para isso é que o AWK / grep / sed não funciona com COM , WMI , ADSI , o Registro, o armazenamento de certificados, etc., etc.

Em outras palavras, o UNIX é um ecossistema inteiro auto-ajustado em torno de arquivos de texto. Como tal, as ferramentas de processamento de texto são efetivamente ferramentas de gerenciamento. O Windows é um ecossistema completamente diferente, auto-ajustado em torno de APIs e objetos. Foi por isso que inventamos o PowerShell.

O que eu acho que você encontrará é que haverá muitas ocasiões em que o processamento de texto não conseguirá o que você deseja no Windows. Nesse ponto, convém pegar o PowerShell. NOTA - não é um negócio de tudo ou nada. No PowerShell, você pode chamar suas ferramentas Unix (e usar o processo de texto ou o processamento de texto do PowerShell). Além disso, você pode ligar para o PowerShell a partir de suas ferramentas Unix e obter texto.

Novamente - não há religião aqui - nosso foco é fornecer as ferramentas necessárias para o sucesso. É por isso que somos tão apaixonados pelo feedback. Deixe-nos saber onde estamos caindo no emprego ou onde você não tem uma ferramenta que você precisa e nós a colocaremos na lista e chegaremos a ela.

Com toda a honestidade, estamos nos cavando de um buraco de 30 anos, por isso vai demorar um pouco. Dito isso, se você pegar a versão beta do Windows Server 2008 / R2 e / ou os betas de nossos produtos para servidores, acho que ficará chocado com a rapidez com que esse buraco está sendo preenchido.

Com relação ao uso - tivemos mais de 3,5 milhões de downloads até o momento. Isso não inclui as pessoas que o usam no Windows Server 2008, porque está incluído como um componente opcional e não precisa de download.

O V2 será enviado em todas as versões do Windows. Ele estará ativado por padrão para todas as edições, exceto o núcleo do servidor, onde é um componente opcional. Logo após o lançamento do Windows 7 / Windows Server 2008 R2, disponibilizaremos o V2 ​​em todas as plataformas, Windows XP e superior. Em outras palavras - seu investimento em aprendizado será aplicável a um número muito grande de máquinas / ambientes.

Um último comentário. Se / quando você começar a aprender o PowerShell, acho que ficará muito feliz. Grande parte do design é fortemente influenciada pelos nossos antecedentes do Unix, portanto, embora sejamos bem diferentes, você o entenderá muito rapidamente (depois de acabar discutindo que não é o Unix :-)).

Sabemos que as pessoas têm um orçamento muito limitado para aprender - é por isso que somos super rígidos quanto à consistência. Você aprenderá algo e depois o usará repetidamente.

Experimentar! Aproveitar! Se empenhar!

grep

Select-StringO cmdlet e o -matchoperador trabalham com regexes. Além disso, você pode usar diretamente o suporte a regex do .NET para obter funcionalidades mais avançadas.

ordenar

Sort-Objecté mais poderoso (do que eu me lembro * do nix sort). Permitindo a classificação em vários níveis em expressões arbitrárias. Aqui, a manutenção do tipo subjacente do PowerShell ajuda; por exemplo, uma DateTimepropriedade será classificada como DateTimesem precisar garantir a formatação em um formato classificável.

uniq

Select-Object -Unique

Perl (a que distância o PowerShell chega dos recursos de Perl?)

Em termos de amplitude de bibliotecas de suporte específicas de domínio do Perl: ainda não chegou nem perto.

Para programação geral, o PowerShell é certamente mais coeso, consistente e fácil de estender. A única lacuna para a troca de texto é algo equivalente ao ..operador de Perl .

AWK

Já faz bastante tempo desde que o AWK foi usado (deve ser> 18 anos, pois mais tarde usei o Perl), então não posso comentar.

sed

[Veja acima]

file (o comando que fornece informações sobre o arquivo)

A força do PowerShell aqui não é muito do que pode fazer com os objetos do sistema de arquivos (e obtém informações completas aqui, dirretornos FileInfoou FolderInfoobjetos, conforme apropriado) é que é o modelo de provedor inteiro.

Você pode tratar o registro, o armazenamento de certificados, o SQL Server, o cache RSS do Internet Explorer, etc. como um espaço de objeto navegável pelos mesmos cmdlets que o sistema de arquivos.

O PowerShell é definitivamente o caminho a seguir no Windows. A Microsoft tornou parte de seus requisitos para futuros produtos não domésticos. Daí suporte rico no Exchange, suporte no SQL Server. Isso só vai se expandir.

Um exemplo recente disso é o TFS PowerToys. Muitas operações do cliente TFS são feitas sem a necessidade de inicializar o tf.exe a cada vez (o que requer uma nova conexão com o servidor TFS, etc.) e é notavelmente mais fácil processar os dados. Além de permitir amplo acesso a toda a API do cliente TFS com mais detalhes do que expostos no Team Explorer do TF.exe.

Como alguém cuja carreira se concentrou no desenvolvimento corporativo do Windows de 1997 a 2010, a resposta óbvia seria o PowerShell por todas as boas razões dadas anteriormente (por exemplo, faz parte da estratégia corporativa da Microsoft; integra-se bem ao Windows / COM / .NET; e o uso de objetos em vez de arquivos fornece um modelo de codificação "mais rico"). Por esse motivo, eu estava usando e promovendo o PowerShell nos últimos dois anos, com a crença expressa de que estava seguindo a "Palavra de Lei".

No entanto, como pragmático, não tenho mais certeza de que o PowerShell seja uma ótima resposta. Embora seja uma excelente ferramenta do Windows e forneça um passo muito necessário para preencher o buraco histórico que é a linha de comando do Windows, enquanto todos observamos o aperto da Microsoft na computação do consumidor, parece cada vez mais provável que a Microsoft tenha uma grande batalha pela frente para manter seu sistema operacional como importante para a empresa do futuro.

De fato, considerando que meu trabalho está cada vez mais em ambientes heterogêneos, estou achando muito mais útil usar scripts Bash no momento, pois eles não apenas funcionam no Linux, Solaris e Mac OS X, mas também funcionam - com o ajuda do Cygwin - no Windows.

Portanto, se você acredita que o futuro do sistema operacional é comoditizado em vez de monopolizado, parece fazer sentido optar por uma estratégia de ferramenta de desenvolvimento ágil que se afaste das ferramentas proprietárias, sempre que possível. Se, no entanto, você vir seu futuro sendo dominado por tudo o que é Redmond, vá para o PowerShell.

Eu usei um pouco do PowerShell para automação de scripts. Embora seja muito bom que o ambiente pareça ter sido pensado muito mais que os shells do Unix, na prática o uso de objetos em vez de fluxos de texto é muito mais desajeitado, e muitas das instalações do Unix que foram desenvolvidas nos últimos 30 ainda faltam anos.

Cygwin ainda é meu ambiente de script preferido para hosts do Windows. Certamente supera as alternativas em termos de realização de tarefas.

Há muitas ótimas respostas aqui, e aqui está minha opinião. O PowerShell está pronto se você estiver ... Exemplos:

grep = " Select-String -Pattern "

sort = "objeto de classificação"

uniq = " Get-Unique "

file = " Get-Item "

cat = " Obter conteúdo "

Perl / AWK / Sed não são comandos, mas os utilitários são difíceis de comparar, mas você pode fazer quase tudo no PowerShell.

Apenas recentemente comecei a me interessar no PowerShell com algum grau de seriedade. Embora, nos últimos sete anos, trabalhe em um ambiente quase exclusivamente baseado no Windows, eu sou do Unix e me pego constantemente tentando "Unix-fy" minha experiência de interação no Windows. É frustrante para dizer o mínimo.

É justo comparar o PowerShell com algo como Bash , tcsh ou zsh, já que utilitários como grep , sed , awk , find etc. não são, estritamente falando, parte do shell; eles sempre farão parte de qualquer ambiente Unix. Dito isto, um comando do PowerShell como o Select-String tem uma função muito semelhante ao grep e é empacotado como um módulo principal no PowerShell ... para que as linhas fiquem um pouco desfocadas.

Eu acho que o principal é a cultura , e o fato de os respectivos conjuntos de ferramentas incorporarem suas respectivas culturas:

• O Unix é uma cultura baseada em arquivo (em geral, não Unicode) baseada em arquivo . Os arquivos de configuração são quase exclusivamente arquivos de texto . O Windows, por outro lado, sempre foi muito mais estruturado em relação aos formatos de configuração - as configurações geralmente são mantidas em bancos de dados proprietários (por exemplo, o registro do Windows) que requerem ferramentas especializadas para seu gerenciamento.

• A interface administrativa (e, por muitos anos, de desenvolvimento) do Unix tradicionalmente tem sido a linha de comando e o terminal virtual. O Windows iniciou como uma GUI e as funções administrativas apenas recentemente começaram a deixar de ser exclusivamente baseadas em GUI. Podemos esperar que a experiência do Unix na linha de comando seja mais rica e madura, dada a liderança significativa que ela tem no PowerShell, e minha experiência corresponde a isso. Sobre isso, na minha experiência:

  • A experiência administrativa do Unix é voltada para facilitar as coisas em uma quantidade mínima de pressionamentos de tecla; isso é provavelmente o resultado da situação histórica de ter que administrar um servidor em uma conexão dial-up lenta de 9600 bauds. Agora PowerShell tem aliases que percorrer um longo caminho para se locomover pela vez detalhado verbo-substantivo padrão, mas para conhecer esses aliases é um pouco de dor (alguém sabe de algo melhor do que: alias | where {$_.ResolvedCommandName -eq "<command>"}?).

    Um exemplo da maneira rica pela qual a história pode ser manipulada:

    iptablesos comandos costumam ser longos e repeti-los com pequenas diferenças seria uma dor se não fosse apenas um dos muitos recursos interessantes de manipulação de histórico incorporados ao Bash , portanto, a inserção de uma regra do iptables como a seguinte:

    iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT

    uma segunda vez para outra câmera (" camera-2"), é apenas um caso de emissão:

    !!:s/-1-/-2-/:s/50/51

    o que significa "executar o comando anterior, mas substitua -1-por -2-e 50com 51.

  • A experiência Unix é otimizada para datilógrafos; pode-se praticamente fazer tudo sem sair da posição "casa". Por exemplo, no Bash , usando as combinações de teclas do Emacs (sim, o Bash também suporta vi bind), percorrer o histórico é feito usando Ctrl-Pe Ctrl-Nenquanto se move para o início e o final de uma linha usando Ctrl-Ae Ctrl-Erespectivamente ... e definitivamente não termina aí. Experimente até a navegação mais simples no console do PowerShell sem sair da posição inicial e você está com problemas.

  • Coisas simples, como paginação versátil (a menos ) no Unix, não parecem estar disponíveis prontamente no PowerShell, o que é um pouco frustrante, e também não existe uma rica experiência de editor. Obviamente, sempre é possível fazer o download de ferramentas de terceiros que preencherão essas lacunas, mas com certeza seria bom se essas coisas estivessem "lá" como se estivessem em praticamente qualquer sabor do Unix.

• A cultura do Windows, pelo menos em termos de APIs do sistema, é impulsionada em grande parte pelas estruturas de suporte, a saber, COM e .NET , ambas altamente estruturadas e baseadas em objetos. Por outro lado, o acesso às APIs do Unix é tradicionalmente realizado por meio de uma interface de arquivo ( /deve /proc) ou (não orientada a objetos) chamadas de biblioteca em estilo C. Não é surpresa, portanto, que as experiências de script correspondam aos respectivos paradigmas do SO. O PowerShell é estruturado por natureza (tudo é um objeto) e baseado em arquivos do Bash e amigos. A API estruturada à disposição de um programador do PowerShell é vasta (essencialmente correspondendo à vastidão do conjunto existente de interfaces COM e .NET padrão).

Em suma, embora os recursos de script do PowerShell sejam indiscutivelmente mais poderosos que o Bash (especialmente quando você considera a disponibilidade do .NET BCL ), a experiência interativa é significativamente mais fraca, principalmente se você estiver utilizando um teclado totalmente controlado por teclado. , perspectiva baseada em console (como muitas cabeças Unix).

Eu não sou um usuário experiente do PowerShell de forma alguma, mas o pouco que eu fui exposto me impressionou bastante. Você pode encadear os cmdlets internos para fazer praticamente qualquer coisa que você possa fazer em um prompt do Unix, e há algumas vantagens adicionais em fazer coisas como exportar para CSV, tabelas HTML e para tipos mais profundos de tarefas de administração do sistema .

E se você realmente precisa de algo como sed , sempre há o UnixUtils ou o GnuWin32 , que você pode integrar com o PowerShell com bastante facilidade.

Como usuário antigo do Unix, no entanto, tive alguns problemas para me acostumar com o esquema de nomeação de comandos e certamente teria me beneficiado mais se soubesse mais sobre o .NET.

Então, basicamente, digo que vale a pena aprendê-lo, se o Windows apenas não representar um problema.

Se você gosta de scripts de shell, vai adorar o PowerShell!

Comece em Uma visita guiada ao Microsoft Command Shell (Ars Technica).

Como meus experimentos recentes me levaram a profundidades das chamadas do PowerShell e .NET, devo dizer que o PowerShell pode substituir o shell Cygwin e Unix.

Não tenho certeza sobre o Perl, mas como o PowerShell e o Perl são Turing completos como linguagens de programação, dou isso como um sim para substituir o Perl também.

Uma coisa que o PowerShell tem acima do Cygwin e do Bash comum no * nix é a capacidade de executar chamadas DLL em área restrita, manipulando o sistema operacional por meio de chamadas diretas à API, métodos WMI e até objetos COM. Que tal iniciar o Internet Explorer via código e depois fazer o que quiser com o documento exibido, emulando efetivamente um back-end para um servidor Web?

Que tal coletar dados de servidores SQL e outros provedores de dados, analisá-los e exportar como CSV, mensagens de email, texto e qualquer tipo de formato de arquivo existente e não existente? (Com habilidades adequadas para criar um arquivo válido com os dados recebidos, é claro, mas o CSV está prontamente disponível).

E há uma segurança extra disponível por meio de cmdlets e scripts assinados, políticas de grupo e políticas de execução que ajudam a impedir que códigos maliciosos sejam executados em seu sistema, mesmo que você os execute como administrador.

Sobre quais comandos são implementados - a resposta de Richard os lista e a capacidade do PowerShell de emular sua funcionalidade já.

Sobre se o PowerShell é forte para garantir a troca - isso é mais uma questão de preferência pessoal, embora cada vez mais serviços do Windows estejam fornecendo cmdlets do PowerShell para controlá-los, não usar o PowerShell com esses serviços presentes é considerado um obstáculo. (O servidor Hyper-V é o principal serviço desse tipo e também oferece a capacidade de fazer mais com os cmdlets do PowerShell do que com a GUI!)

Provavelmente, essa resposta está atrasada cinco anos, mas ainda assim, se alguém executar tarefas administrativas ou scripts gerais de várias coisas no Windows, definitivamente deve tentar aproveitar o PowerShell para seus propósitos.

Ao comparar o PowerShell à combinação Cygwin / Perl / Shell, saiba que o PowerShell representa apenas a parte "Shell" dessa combinação.

No entanto, você pode invocar qualquer comando do PowerShell da mesma forma que o cmd.exe ou o Cygwin. Ele não reimplementa as funções especificadas e certamente não é comparável ao Perl.

É "apenas" um shell, mas facilita a programação, fornecendo uma interface confortável para o universo .NET.

Lembre-se também de que o PowerShell requer Windows XP, Windows Server 2003 ou superior, o que pode representar um problema, dependendo da sua infraestrutura de TI.

Atualizar:

Eu não tinha ideia de que tipo de debate filosófico minha resposta provocaria.

Postei minha resposta no contexto da pergunta: Compare o PowerShell ao Cygwin, Perl e Bash.

O PowerShell é um shell, pois não faz diferença sintática entre comandos internos, comandos, funções do usuário e comandos externos (.exe, .bat, .cmd). Chamar apenas métodos .NET diferem adicionando um espaço para nome ou um objeto na chamada.

Sua capacidade de programação deriva da estrutura .NET, não de nada específico da "linguagem" do PowerShell.

Eu diria que acredito que o PowerShell é uma "linguagem de script" assim que o Bugzilla ou o MediaWiki são implementados como scripts do PowerShell em execução em um servidor Web;)

Até lá, aproveite as comparações .

Os cmdlets no PowerShell são muito agradáveis ​​e funcionam de maneira confiável. A orientação a objetos deles me atrai muito, já que sou desenvolvedor Java / C #, mas não é de todo um conjunto completo. Como é orientado a objetos, perdeu muito da maturidade do fluxo de texto do conjunto de ferramentas POSIX ( awke sedpara citar alguns).

A melhor resposta que encontrei para o dilema de amar técnicas OO e amar a maturidade nas ferramentas POSIX é usar as duas! Um ótimo aspecto do PowerShell é que ele realiza um excelente trabalho de canalização de objetos para fluxos padrão. O PowerShell, por padrão, usa um pipeline de objetos para transportar seus objetos. Esses não são os fluxos padrão (saída padrão, erro padrão e entrada padrão). Quando o PowerShell precisa passar a saída para um processo padrão que não possui um pipeline de objetos, ele primeiro converte os objetos em um fluxo de texto. Como faz isso tão bem, o PowerShell é um excelente local para hospedar ferramentas POSIX!

O melhor conjunto de ferramentas POSIX é o GnuWin32 . Demora mais de 5 segundos para instalar, mas vale a pena, e até onde eu sei, não modifica seu sistema (registro, c:\windows\*pastas, etc.), exceto a cópia de arquivos para os diretórios que você especificar. Isso é muito interessante, porque se você colocar as ferramentas em um diretório compartilhado, muitas pessoas poderão acessá-las simultaneamente.

Instruções de instalação do GnuWin32

Faça o download e execute o exe (é do site SourceForge ) apontando-o para um diretório adequado (eu vou usar C:\bin). Ele criará um GetGnuWin32diretório no qual você executará e download.bat, em seguida install.bat(sem parâmetros), após o qual, haverá um C:\bin\GetGnuWin32\gnuwin32\bindiretório que é a pasta mais útil que já existiu em uma máquina Windows. Adicione esse diretório ao seu caminho e você estará pronto para começar.

TL; DR - Eu não odeio o Windows ou o PowerShell. Eu simplesmente não consigo fazer nada no Windows ou no PowerShell.

Pessoalmente, ainda acho o PowerShell na melhor das hipóteses.

• a conclusão da guia dos caminhos do diretório não é composta, exigindo que o usuário insira um separador de caminho após cada conclusão do nome.
• Eu ainda me sinto como o Windows não tem sequer o conceito de um caminho ou do que um caminho é, sem acessível ao usuário indicador de casa ~/curta de alguns@environment://somejibberish/%user_home%

• O NTFS ainda está uma bagunça e, aparentemente, sempre será. Boa sorte para navegar.

• interface cmd-esque, o dinosaur cmd.exe ainda está visível no PowerShell, Editar → Marcar ainda sendo a única maneira de copiar informações e copiar somente na forma de blocos retangulares do espaço visível do terminal. e Editar → Marcar ainda sendo a única maneira de colar seqüências de caracteres no terminal.

• Pintá-lo de azul não o torna mais atraente. Não me importo que os desenvolvedores da Microsoft tenham um gosto colorido.

• O Windows sempre abre no canto superior esquerdo da tela. Para alguém que usa barras de tarefas verticais, isso é incrivelmente irritante, especialmente considerando que a barra de tarefas do Windows cobrirá o único canto da janela que dá acesso à funcionalidade de copiar / colar.

Não posso falar muito com base nas ferramentas que o Windows inclui. Sendo que existe um conjunto inteiro de ferramentas CLI de código aberto e licenciadas gratuitamente, e o PowerShell é fornecido, pelo que sei, nenhuma delas é uma decepção absoluta.

• PowerShell's wget leva argumentos aparentemente incomparáveis ​​para o GNU wget. Obrigado, vislumbre de esperança portável - inútil.
• O PowerShell POSIX não é compatível com Bash, principalmente o &&operador não é tratado, tornando o comando condicional mais simples.

Eu não conheço homem; Eu tentei, realmente fiz; Ainda tento tentar, na esperança de que da próxima vez que o abrir, seja menos inútil. Não posso fazer nada no PowerShell e mal consigo fazer coisas com um projeto real para trazer as ferramentas GNU para o Windows.

O MySysGit me fornece o prompt do dinosaur cmd.exe com algumas ferramentas GNU, e ainda é muito desanimador, mas finalmente a conclusão do caminho funciona. E o comando Git será executado no Git Bash.

O Mintty for MySysGit fornece à interface do Cygwin o ambiente do mysysgit, tornando uma coisa para copiar e colar (selecione para copiar (mouse), Shift+ Inspara colar, quão moderno ...). No entanto, coisas comogit push estão quebradas em Mintty.

Não pretendo reclamar, mas ainda vejo grandes problemas com a usabilidade da linha de comando no Windows, mesmo com ferramentas como o Cygwin.

PS: Só porque algo pode ser feito no PowerShell, não o torna utilizável . A usabilidade é mais profunda que a capacidade e é o que tento focar ao tentar usar um produto como consumidor.

Não vi que o PowerShell realmente decolou, pelo menos ainda não. Portanto, pode não valer a pena o esforço de aprendê-lo, a menos que os outros da sua equipe já o conheçam.

Para sua situação, você pode se sair melhor com uma linguagem de script que outras pessoas podem adotar, Perl como você mencionou, ou outras como Ruby ou Python.

Eu acho que muito disso depende do que você precisa fazer. Pessoalmente, tenho usado o Python para meus próprios scripts pessoais, mas sei que quando começar a escrever algo que nunca poderei transmitir - por isso tento não fazer algo muito revolucionário.

Por que não usar os dois? Chame scripts do PowerShell no Cygwin como qualquer outro script interpretado como Perl, etc.

Eu faço isso o suficiente para escrever https://bitbucket.org/jbianchi/powershell para um wrapper Bash chamar o powershell.exe no Cygwin. Ele pode ser usado como um shebang como a primeira linha de um script .ps1 do powershell.exe (já que o PowerShell também usa "#" como comentário). Veja https://bitbucket.org/jbianchi/powershell/wiki/Home para exemplos

Em algumas linhas, Cygwin e PowerShell são ferramentas diferentes; no entanto, se você tiver o Cygwin instalado, poderá executar os executáveis ​​do Cygwin em uma sessão do PowerShell. Eu me acostumei tanto ao PowerShell que agora não uso mais grep, sort, awk, etc. Existem várias alternativas internas no PowerShell e, caso contrário, você pode encontrar um cmdlet por aí.

A principal ferramenta que me vejo usando é o ssh.exe, mas em uma sessão do PowerShell.

Isso funciona muito bem.

Achei que a programação do PowerShell não vale o esforço.

Tenho vários anos de experiência com scripts de shell no Unix, mas achei extremamente difícil fazer muita coisa com o PowerShell.

Parece que muitas funções exigem que você interrogue a Interface de Gerenciamento do Windows e emita comandos semelhantes a SQL para obter as informações necessárias.

Por exemplo, eu queria escrever um script para remover todos os arquivos com um sufixo específico de uma árvore de diretórios. No Unix, isso seria um simples ...

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

Depois de algumas horas brincando com Scripting.FileSystemObjecte WScript.Shellemitindo "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & path =' "& searchFolder &" '", finalmente desisti e aceitei a Pesquisa do Windows Explorer de comando e faça-o manualmente. Provavelmente, há alguma maneira de fazer o que eu queria, mas não vi nada óbvio e todos os exemplos no site do MSDN eram tão triviais que não tinham valor.

EDIT Heh, é claro que, assim que escrevi isso, examinei um pouco mais e descobri o que estava perdendo: a -recurseopção para o comando remove-item está com defeito (revelada se você usar get-help remove-item -detailed).

Eu estava tentando "remove-item -filter '* .xyz' -recurse" e não estava funcionando, então desisti.

Acontece que você precisa usar get-childitem -filter '*.xyz' -recurse | remove-item

Você também pode tentar executar scripts do Bash no Windows usando o BashWin em https://github.com/skanga/BashWin .

O PowerShell é muito poderoso, mais poderoso do que os built-ins padrão dos shells do Unix (mas apenas porque inclui grande parte da funcionalidade geralmente concedida aos subprogramas). Além disso, considere que você pode escrever applets em qualquer linguagem .NET, incluindo IronPython , IronRuby , PerlNet, etc .. ou você pode simplesmente chamar seus comandos Cygwin de PowerShell, ignorando todas as funcionalidades extra e ele vai trabalhar de forma semelhante ao Bash, KornShell , como queiras...