PowerShell è pronto a sostituire la mia shell Cygwin su Windows? [chiuso]

Sto discutendo se dovrei imparare PowerShell o semplicemente attenermi agli script Cygwin / Perl / script shell Unix, ecc.

Il vantaggio di PowerShell sarebbe che gli script potrebbero essere più facilmente utilizzati dai compagni di squadra che non hanno Cygwin; tuttavia, non so se scriverei davvero tanti script per scopi generici o se le persone li userebbero addirittura.

Lo scripting Unix è così potente, PowerShell è abbastanza vicino da giustificare il passaggio?

Ecco alcune delle cose specifiche (o equivalenti) che avrei cercato in PowerShell:

• grep
• ordinare
• uniq
• Perl (quanto è vicino PowerShell alle capacità di Perl?)
• AWK
• sed
• file (il comando che fornisce informazioni sul file)
• eccetera.

Gli strumenti sono solo strumenti.
Aiutano o no.
Hai bisogno di aiuto o no.

Se conosci Unix e quegli strumenti fanno quello che ti serve per fare su Windows, allora sei un ragazzo felice e non c'è bisogno di imparare PowerShell (a meno che tu non voglia esplorare).

Il mio intento originale era quello di includere una serie di strumenti Unix in Windows e di farcela (alcuni di noi nel team hanno profondi background Unix e una buona dose di rispetto per quella comunità.)

Quello che ho scoperto è che questo non ha aiutato molto. Il motivo è che AWK / grep / sed non funzionano su COM , WMI , ADSI , il Registro di sistema, l'archivio certificati, ecc., Ecc.

In altre parole, UNIX è un intero ecosistema ottimizzato per i file di testo. Pertanto, gli strumenti di elaborazione del testo sono strumenti di gestione efficaci. Windows è un ecosistema completamente diverso, ottimizzato per API e oggetti. Ecco perché abbiamo inventato PowerShell.

Quello che penso che scoprirai è che ci saranno molte occasioni in cui l'elaborazione del testo non ti porterà quello che vuoi su Windows. A quel punto, ti consigliamo di prendere PowerShell. NOTA: non è un affare tutto o niente. All'interno di PowerShell, puoi chiamare i tuoi strumenti Unix (e usare il loro processo di testo o l'elaborazione del testo di PowerShell). Inoltre puoi chiamare PowerShell dai tuoi strumenti Unix e ottenere testo.

Ancora una volta - non c'è religione qui - il nostro obiettivo è darti gli strumenti di cui hai bisogno per avere successo. Ecco perché siamo così appassionati del feedback. Facci sapere dove stiamo cadendo sul posto di lavoro o dove non hai uno strumento di cui hai bisogno e lo inseriremo nell'elenco e arriveremo ad esso.

In tutta onestà, ci stiamo scavando da una buca di 30 anni, quindi ci vorrà del tempo. Detto questo, se raccogli la beta di Windows Server 2008 / R2 e / o le versioni beta dei nostri prodotti server, penso che rimarrai scioccato dalla rapidità con cui si riempie quel buco.

Per quanto riguarda l'utilizzo, ad oggi abbiamo avuto> 3,5 milioni di download. Ciò non include le persone che lo utilizzano in Windows Server 2008, perché è incluso come componente facoltativo e non necessita di download.

V2 verrà spedito in tutte le versioni di Windows. Sarà attivo per impostazione predefinita per tutte le edizioni ad eccezione del Server core in cui è un componente opzionale. Poco dopo la spedizione di Windows 7 / Windows Server 2008 R2, renderemo V2 disponibile su tutte le piattaforme, Windows XP e versioni successive. In altre parole, il tuo investimento nell'apprendimento sarà applicabile a un numero molto elevato di macchine / ambienti.

Un ultimo commento Se / quando inizi a imparare PowerShell, penso che sarai abbastanza felice. Gran parte del design è fortemente influenzato dai nostri sfondi Unix, quindi mentre siamo abbastanza diversi, lo raccoglierai molto rapidamente (dopo aver superato la maledizione che non è Unix :-)).

Sappiamo che le persone hanno un budget molto limitato per l'apprendimento, ecco perché siamo super-core riguardo alla coerenza. Imparerai qualcosa, e poi lo utilizzerai più e più volte.

Sperimentare! Godere! Engage!

grep

Select-Stringcmdlet e -matchoperatore lavorano con regex. Inoltre puoi utilizzare direttamente il supporto regex di .NET per funzionalità più avanzate.

ordinare

Sort-Objectè più potente (di quanto ricordo di * nix sort). Consentire l'ordinamento multilivello su espressioni arbitrarie. Qui aiuta il mantenimento del tipo di base di PowerShell; ad esempio una DateTimeproprietà verrà ordinata come a DateTimesenza dover garantire la formattazione in un formato ordinabile.

uniq

Select-Object -Unique

Perl (quanto è vicino PowerShell alle funzionalità Perl?)

In termini di ampiezza delle librerie di supporto specifiche per dominio di Perl: da nessuna parte (ancora).

Per la programmazione generale, PowerShell è sicuramente più coerente e coerente e più facile da estendere. L'unico divario per il munging del testo è qualcosa di equivalente all'operatore di Perl ...

AWK

È passato abbastanza tempo dall'utilizzo di AWK (deve essere> 18 anni, da quando ho appena usato Perl), quindi non posso davvero commentare.

sed

[Vedi sopra]

file (il comando che fornisce informazioni sul file)

Il punto di forza di PowerShell qui non è molto di quello che può fare con gli oggetti del filesystem (e ottiene informazioni complete qui, dirritorni FileInfoo FolderInfooggetti come appropriato) è che è l'intero modello di provider.

È possibile trattare il registro, l'archivio certificati, SQL Server, la cache RSS di Internet Explorer, ecc. Come spazio oggetti navigabile dagli stessi cmdlet del filesystem.

PowerShell è sicuramente la strada da percorrere su Windows. Microsoft ha reso parte dei loro requisiti per i futuri prodotti non domestici. Da qui il supporto completo in Exchange, il supporto in SQL Server. Questo si espanderà soltanto.

Un esempio recente di questo è i PowerToys TFS. Molte operazioni client TFS vengono eseguite senza dover avviare tf.exe ogni volta (che richiede una nuova connessione al server TFS, ecc.) Ed è notevolmente più semplice quindi elaborare ulteriormente i dati. Oltre a consentire un ampio accesso all'intera API client TFS a un dettaglio maggiore di quello esposto in Team Explorer di TF.exe.

Come persona la cui carriera si è concentrata sullo sviluppo aziendale di Windows dal 1997 al 2010, la risposta ovvia sarebbe PowerShell per tutti i buoni motivi indicati in precedenza (ad esempio, fa parte della strategia aziendale di Microsoft; si integra bene con Windows / COM / .NET; e l'utilizzo di oggetti anziché di file fornisce un modello di codifica "più ricco"). Per questo motivo ho usato e promosso PowerShell negli ultimi due anni circa, con l'esplicita convinzione di seguire la "Parola di Bill".

Tuttavia, come pragmatico non sono più sicuro che PowerShell sia una risposta così grande. Sebbene sia un eccellente strumento di Windows e fornisca un passo molto necessario per colmare il buco storico che è la riga di comando di Windows, poiché tutti guardiamo la presa di Microsoft sulla scivolata dell'elaborazione dei consumatori, sembra sempre più probabile che Microsoft abbia una battaglia enorme in vista per mantenere il suo sistema operativo come importante per l'impresa del futuro.

Infatti, dato che trovo che il mio lavoro sia sempre più in ambienti eterogenei, sto trovando molto più utile utilizzare gli script Bash al momento, poiché non funzionano solo su Linux, Solaris e Mac OS X, ma funzionano anche con aiuto di Cygwin — su Windows.

Quindi, se si acquista la convinzione che il futuro del sistema operativo sia mercificato piuttosto che monopolizzato, allora ha senso optare per una strategia di strumento di sviluppo agile che si allontani da strumenti proprietari ove fattibile. Se tuttavia vedi che il tuo futuro è dominato da tutto ciò che è Redmond, scegli PowerShell.

Ho usato un po 'di PowerShell per l'automazione degli script. Mentre è molto bello che l'ambiente sembra essere stato pensato molto più delle shell Unix, in pratica l'uso di oggetti anziché flussi di testo è molto più goffo e molte delle strutture Unix che sono state sviluppate negli ultimi 30 mancano ancora anni.

Cygwin è ancora il mio ambiente di scripting preferito dagli host Windows. Certamente batte le alternative in termini di fare le cose.

Ci sono molte ottime risposte qui, ed ecco la mia opinione. PowerShell è pronto se sei ... Esempi:

grep = " Select-String -Pattern "

sort = "Sort-Object"

uniq = " Get-Unique "

file = " Get-Item "

cat = " Get-Content "

Perl / AWK / Sed non sono comandi, ma utilità quindi difficili da confrontare, ma in PowerShell puoi fare quasi tutto.

Di recente ho iniziato a dilettarmi con PowerShell con serietà. Anche se negli ultimi sette anni ho lavorato in un ambiente basato quasi esclusivamente su Windows, vengo da un background Unix e mi trovo costantemente a provare a "Unix-fy" la mia esperienza di interazione su Windows. È a dir poco frustrante.

È giusto paragonare PowerShell a qualcosa come Bash , tcsh o zsh poiché utilità come grep , sed , awk , find , ecc. Non fanno, a rigor di termini, parte della shell; faranno comunque parte di qualsiasi ambiente Unix. Detto questo, un comando PowerShell come Select-String ha una funzione molto simile a grep ed è raggruppato come modulo principale in PowerShell ... quindi le linee possono essere un po 'sfocate.

Penso che la cosa chiave sia la cultura e il fatto che i rispettivi set di strumenti incarneranno le loro rispettive culture:

• Unix è una cultura testuale basata su file (in generale, non Unicode) . I file di configurazione sono quasi esclusivamente file di testo . Windows, d'altra parte, è sempre stato molto più strutturato rispetto ai formati di configurazione - le configurazioni sono generalmente mantenute in database proprietari (ad esempio, il registro di Windows) che richiedono strumenti specializzati per la loro gestione.

• L'interfaccia amministrativa di Unix (e, per molti anni, di sviluppo) è stata tradizionalmente la riga di comando e il terminale virtuale. Windows è stato avviato come una GUI e solo recentemente le funzioni amministrative hanno iniziato ad allontanarsi dall'essere basate esclusivamente sulla GUI. Possiamo aspettarci che l'esperienza Unix sulla riga di comando sia più ricca e matura, dato il notevole vantaggio che ha su PowerShell e la mia esperienza corrisponde. Su questo, nella mia esperienza:

  • L'esperienza amministrativa di Unix è orientata a rendere le cose facili da fare in un numero minimo di tratti chiave; questo è probabilmente il risultato della situazione storica di dover amministrare un server su una connessione dial-up da 9600 baud lenta. Adesso PowerShell ha degli alias che fanno molto per aggirare lo standard Verb-Noun piuttosto prolisso , ma conoscere quegli alias è un po 'una seccatura (qualcuno sa qualcosa di meglio di alias | where {$_.ResolvedCommandName -eq "<command>"}:?).

    Un esempio del modo ricco in cui la storia può essere manipolata:

    iptablesi comandi sono spesso prolissi e ripeterli con lievi differenze sarebbe un dolore se non fosse solo per una delle tante belle funzioni di manipolazione della storia incorporate in Bash , quindi inserire una regola iptables come la seguente:

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

    una seconda volta per un'altra fotocamera (" camera-2"), è solo un caso di emissione:

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

    che significa "esegui il comando precedente, ma sostituiscilo -1-con -2-e 50con 51.

  • L'esperienza Unix è ottimizzata per i dattilografi; si può praticamente fare tutto senza uscire dalla posizione "home". Ad esempio, in Bash , usando le associazioni dei tasti Emacs (sì, Bash supporta anche le associazioni vi ), scorrere la cronologia viene fatto usando Ctrl-Pe Ctrl-Nmentre si passa all'inizio e alla fine di una linea usando Ctrl-Ae Ctrl-Erispettivamente ... e sicuramente non finisce qui. Prova anche la navigazione più semplice nella console di PowerShell senza spostarti dalla posizione iniziale e sei nei guai.

  • Cose semplici come il paging versatile (un po 'meno ) su Unix non sembrano essere disponibili immediatamente in PowerShell, il che è un po' frustrante e non esiste nemmeno una ricca esperienza di editor. Ovviamente, si possono sempre scaricare strumenti di terze parti che colmeranno queste lacune, ma sarebbe sicuramente bello se queste cose fossero semplicemente "lì" come se fossero praticamente su qualsiasi sapore di Unix.

• La cultura di Windows, almeno in termini di API di sistema, è in gran parte guidata dai framework di supporto, vale a dire, COM e .NET , entrambi i quali sono altamente strutturati e basati su oggetti. D'altra parte, l'accesso alle API di Unix è stato tradizionalmente attraverso un'interfaccia di file ( /deve /proc) o chiamate di libreria in stile C (non orientate agli oggetti). Non sorprende quindi che le esperienze di scripting corrispondano ai rispettivi paradigmi del sistema operativo. PowerShell è strutturato per natura (tutto è un oggetto) e basato su file Bash e amici. L'API strutturata che è a disposizione di un programmatore PowerShell è vasta (essenzialmente corrispondente alla vastità del set esistente di interfacce COM e .NET standard).

In breve, sebbene le funzionalità di scripting di PowerShell siano probabilmente più potenti di Bash (specialmente se si considera la disponibilità di .NET BCL ), l' esperienza interattiva è significativamente più debole, in particolare se ci si arriva da un sistema interamente guidato dalla tastiera , prospettiva basata su console (come lo sono molte teste Unix).

Non sono assolutamente un utente esperto di PowerShell, ma il poco a cui sono stato esposto mi ha impressionato moltissimo. È possibile concatenare i cmdlet incorporati per fare praticamente tutto ciò che si potrebbe fare al prompt di Unix, e c'è qualche ulteriore bontà nel fare cose come esportare in CSV, tabelle HTML e per lavori di amministrazione del sistema più approfonditi .

E se hai davvero bisogno di qualcosa come sed , c'è sempre UnixUtils o GnuWin32 , che potresti integrare con PowerShell abbastanza facilmente.

Come utente Unix di lunga data, tuttavia, ho avuto un po 'di problemi ad abituarmi allo schema di denominazione dei comandi e sicuramente ne avrei beneficiato di più se avessi saputo più .NET.

Quindi, in sostanza, dico che vale la pena impararlo se la sola funzionalità di Windows non rappresenta un problema.

Se ti piacciono gli script di shell, adorerai PowerShell!

Inizia da una visita guidata di Microsoft Command Shell (Ars Technica).

Poiché i miei recenti esperimenti mi hanno portato ad approfondire le chiamate PowerShell e .NET, devo dire che PowerShell può sostituire Cygwin e Unix shell.

Non sono sicuro di Perl, ma poiché sia ​​PowerShell che Perl sono Turing completi come linguaggi di programmazione, lo dò come un sì per sostituire anche Perl.

Una cosa che PowerShell ha sopra Cygwin e Bash ordinario sotto * nix, è la sua capacità di eseguire chiamate DLL sandbox, manipolando il sistema operativo tramite chiamate API dirette, metodi WMI e persino oggetti COM. Che ne dici di avviare Internet Explorer tramite codice, quindi fare quello che vuoi con il suo documento visualizzato, emulare efficacemente un back-end per un server Web?

Che ne dite di raccogliere dati da server SQL e altri fornitori di dati, analizzarli ed esportarli come CSV, messaggi di posta, testo e in realtà qualsiasi tipo di formati di file esistenti e non esistenti? (Naturalmente, con le competenze adeguate per creare un file valido dai dati ricevuti, ma CSV sono prontamente disponibili).

Inoltre, è disponibile una sicurezza aggiuntiva tramite cmdlet e script firmati, criteri di gruppo e criteri di esecuzione che aiutano a impedire l'esecuzione di codice dannoso sul sistema anche se eseguito come amministratore.

Informazioni sui comandi implementati: la risposta di Richard li elenca e la capacità di PowerShell di emulare già la loro funzionalità.

Indicare se PowerShell è forte per giustificare il passaggio - questa è più una questione di preferenza personale, anche se sempre più servizi Windows forniscono cmdlet PowerShell per controllarli, non utilizzare PowerShell con questi servizi presenti è considerato un ostacolo. (Il server Hyper-V è il principale servizio di questo tipo e offre anche la possibilità di fare di più con i cmdlet di PowerShell che con la GUI!)

Probabilmente questa risposta è in ritardo di cinque anni, ma comunque, se qualcuno esegue attività amministrative o script generali di varie cose su Windows, dovrebbe sicuramente provare a sfruttare PowerShell per i suoi scopi.

Quando si confronta PowerShell con la combinazione Cygwin / Perl / Shell, tenere presente che PowerShell rappresenta solo la parte "Shell" di quella combinazione.

È comunque possibile richiamare qualsiasi comando da PowerShell proprio come si fa da cmd.exe o Cygwin. Esso non ri-attuare le funzioni specificate, e non è certamente paragonabile a Perl.

È "solo" una shell, ma semplifica la programmazione fornendo un'interfaccia comoda per l'universo .NET.

Inoltre, tieni presente che PowerShell richiede Windows XP, Windows Server 2003 o versioni successive, il che può comportare un problema a seconda della tua infrastruttura IT.

Aggiornare:

Non avevo idea di che tipo di dibattito filosofico la mia risposta avrebbe suscitato.

Ho pubblicato la mia risposta nel contesto della domanda: confronta PowerShell con Cygwin, Perl e Bash.

PowerShell è una shell, poiché non fa alcuna differenza sintattica tra comandi integrati, commandlet, funzioni utente e comandi esterni (.exe, .bat, .cmd). Solo il richiamo dei metodi .NET differisce aggiungendo uno spazio dei nomi o un oggetto nella chiamata.

La sua programmabilità deriva dal framework .NET, non da qualcosa di specifico del "linguaggio" di PowerShell.

Direi che credo che PowerShell sia un "linguaggio di scripting" non appena Bugzilla o MediaWiki vengono implementati come script PowerShell in esecuzione su un server Web;)

Fino ad allora, goditi i confronti .

I cmdlet in PowerShell sono molto belli e funzionano in modo affidabile. La loro orientazione agli oggetti mi attira molto dal momento che sono uno sviluppatore Java / C #, ma non è affatto un set completo. Poiché è orientato agli oggetti, ha perso gran parte della maturità del flusso di testo del set di strumenti POSIX ( awke sedper citarne alcuni).

La migliore risposta che ho trovato al dilemma di amare le tecniche OO e amare la maturità negli strumenti POSIX è usare entrambe! Un ottimo aspetto di PowerShell è che svolge un lavoro eccellente eseguendo il piping di oggetti su flussi standard. Per impostazione predefinita, PowerShell utilizza una pipeline di oggetti per trasportare i suoi oggetti. Questi non sono i flussi standard (standard out, errore standard e standard in). Quando PowerShell deve passare l'output a un processo standard che non ha una pipeline di oggetti, per prima cosa converte gli oggetti in un flusso di testo. Dal momento che lo fa così bene, PowerShell è un posto eccellente per ospitare strumenti POSIX!

Il miglior set di strumenti POSIX è GnuWin32 . L'installazione richiede più di 5 secondi, ma ne vale la pena e, per quanto ne so, non modifica il sistema (registro, c:\windows\*cartelle, ecc.) Ad eccezione della copia dei file nelle directory specificate. Questo è molto utile perché se metti gli strumenti in una directory condivisa, molte persone possono accedervi contemporaneamente.

Istruzioni per l'installazione di GnuWin32

Scarica ed esegui l' exe (proviene dal sito SourceForge ) puntandolo a una directory adatta (che userò C:\bin). Verrà creata una GetGnuWin32directory in cui verrà eseguita download.bat, quindi install.bat(senza parametri), dopo di che, ci sarà una C:\bin\GetGnuWin32\gnuwin32\bindirectory che è la cartella più utile che sia mai esistita su un computer Windows. Aggiungi quella directory al tuo percorso e sei pronto per partire.

TL; DR - Non odio Windows o PowerShell. Non riesco proprio a fare nulla in Windows o su PowerShell.

Personalmente trovo ancora poco incoraggiante PowerShell.

• il completamento della scheda dei percorsi di directory non è composto, richiedendo all'utente di inserire un separatore di percorso dopo ogni completamento del nome.
• Sento ancora che Windows non ha nemmeno il concetto di un percorso o di cosa sia un percorso, senza un indicatore home utente accessibile a ~/parte alcuni@environment://somejibberish/%user_home%

• NTFS è ancora un casino e apparentemente lo sarà sempre. Buona fortuna a navigare.

• Interfaccia cmd-esque, Il dinosauro cmd.exe è ancora visibile in PowerShell, Modifica → Segna ancora l'unico modo per copiare le informazioni e copiarle solo sotto forma di blocchi rettangolari di spazio terminale visibile. e Modifica → Segna come unico modo per incollare le stringhe nel terminale.

• Dipingerlo di blu non lo rende più attraente. Non mi dispiace però che gli sviluppatori Microsoft abbiano un gusto per i colori.

• Windows si apre sempre nell'angolo in alto a sinistra dello schermo. Per qualcuno che utilizza le barre delle attività verticali questo è incredibilmente fastidioso, soprattutto considerando che la barra delle attività di Windows coprirà l'unico angolo della finestra che dà accesso alla funzionalità copia / incolla.

Non posso parlare molto sulla base degli strumenti inclusi in Windows. Essendo che esiste un intero set di strumenti CLI open source e con licenza gratuita e PowerShell viene fornito, a mia conoscenza, nessuno di questi è una vera delusione.

• PowerShell wgetaccetta argomenti apparentemente incomparabili su GNU wget. Grazie, barlume di speranza portabilmente inutile.
• PowerShell POSIX non è compatibile con Bash, in particolare l' &&operatore non viene gestito, il che rende il comando condizionale più semplice dopo non una cosa.

Non conosco l'uomo; Ci ho provato, l'ho fatto davvero; Cerco ancora di provarlo nella speranza che la prossima volta che lo apro sarà meno inutile. Non riesco a fare nulla in PowerShell e riesco a malapena a fare le cose con un vero progetto per portare gli strumenti GNU su Windows.

MySysGit mi dà il prompt dinosauro cmd.exe con un paio di strumenti GNU, ed è ancora molto deludente, ma alla fine il completamento del percorso funziona. E il comando Git verrà eseguito in Git Bash.

Mintty per MySysGit fornisce l'interfaccia Cygwin sull'ambiente di mysysgit, facendo copia e incolla qualcosa (selezionare per copiare (mouse), Shift+ Insper incollare, come moderno ...). Tuttavia, cose come git pushsono rotte in Mintty.

Non intendo rantolare, ma vedo ancora enormi problemi con l'usabilità della riga di comando su Windows, anche con strumenti come Cygwin.

PS: Solo perché qualcosa può essere fatto in PowerShell, non lo rende utilizzabile . L'usabilità è più profonda dell'abilità ed è ciò su cui tendo a concentrarmi quando cerco di utilizzare un prodotto come consumatore.

Non ho visto che PowerShell è davvero decollato, almeno non ancora. Quindi potrebbe non valere la pena apprenderlo a meno che gli altri membri del tuo team non lo sappiano già.

Per la tua situazione potresti stare meglio con un linguaggio di scripting che altri potrebbero avere dietro, Perl come hai menzionato, o altri come Ruby o Python.

Penso che molto dipenda da cosa devi fare. Personalmente sto usando Python per i miei script personali, ma so quando comincio a scrivere qualcosa che non sarò mai in grado di trasmettere - quindi cerco di non fare nulla di troppo rivoluzionario.

Perché non usare entrambi? Chiama gli script PowerShell in Cygwin come qualsiasi altro script interpretato come Perl, ecc.

Faccio questo abbastanza da aver scritto https://bitbucket.org/jbianchi/powershell affinché un wrapper Bash chiami powershell.exe in Cygwin. Può essere usato come shebang come prima riga di uno script .ps1 powershell.exe (poiché PowerShell utilizza anche "#" come commento). Vedi https://bitbucket.org/jbianchi/powershell/wiki/Home per esempi

In un paio di righe, Cygwin e PowerShell sono strumenti diversi, tuttavia se hai Cygwin installato puoi eseguire gli eseguibili Cygwin all'interno di una sessione di PowerShell. Mi sono così abituato a PowerShell che ora non uso più grep, sort, awk, ecc. Ci sono praticamente alternative integrate in PowerShell e, in caso contrario, puoi trovare un cmdlet.

Lo strumento principale che mi trovo a utilizzare è ssh.exe, ma all'interno di una sessione di PowerShell.

Funziona benissimo.

Ho trovato che la programmazione di PowerShell non valeva la pena.

Ho diversi anni di esperienza con gli script di shell in Unix, ma ho trovato enormemente difficile fare qualsiasi cosa con PowerShell.

Sembra che molte funzioni richiedano di interrogare l'interfaccia di gestione di Windows ed emettere comandi simili a SQL per ottenere le informazioni necessarie.

Ad esempio, volevo scrivere uno script per rimuovere tutti i file con un suffisso specifico da un albero di directory. Sotto Unix, questo sarebbe un semplice ...

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

Dopo un paio d'ore cazzeggiare con Scripting.FileSystemObjecte WScript.Shelle il rilascio "SELECT * FROM Win32_ShortcutFile dove unità = '" & Drive & ' 'e il percorso ='' & SearchFolder & "'", Alla fine ho rinunciato e optato per di Esplora risorse di Windows Search di comando e fallo manualmente. Probabilmente c'è un modo per fare quello che volevo, ma non ho visto nulla di ovvio e tutti gli esempi sul sito MSDN erano così banali da essere inutili.

EDIT Heh, ovviamente non appena ho scritto questo, ho dato un'occhiata in giro e ho scoperto cosa mi mancava: l' -recurseopzione per il comando remove-item è difettosa (rivelata se si utilizza get-help remove-item -detailed).

Avevo provato "remove-item -filter '* .xyz' -recurse" e non funzionava, quindi ho rinunciato.

Si scopre che devi usare get-childitem -filter '*.xyz' -recurse | remove-item

Puoi anche provare a eseguire script Bash su Windows usando BashWin su https://github.com/skanga/BashWin .

PowerShell è molto potente, più potente dei built-in standard delle shell Unix (ma solo perché include gran parte delle funzionalità normalmente sborsate nei sottoprogrammi). Inoltre, considera che puoi scrivere applet in qualsiasi linguaggio .NET, inclusi IronPython , IronRuby , PerlNet, ecc. Oppure puoi semplicemente chiamare i tuoi comandi Cygwin da PowerShell, ignorando tutte le funzionalità extra e funzionerà in modo simile a Bash, KornShell , o qualunque cosa ...