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


384

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.

7
Non direi che ero interessato a raccogliere Powershell, ho trovato questa pagina e ora conosco le differenze generali tra PS e gli script di shell a cui sono abituato.
Bender the Greatest il

5
Questo post è improvvisamente salito dalle ceneri in una presentazione di collegamento HN. Ottimo lavoro. E male per @Bobby per aver chiuso questo come non costruttivo.
Sid,

26
Se qualcuno non può chiedere in che modo uno strumento replica le funzioni di un altro, SO non può rispondere alle domande sul confronto degli strumenti. Questo è attentamente formulato per evitare polemiche, ma è stato presumibilmente trascurato "controverso" semplicemente per apparire come una domanda Unix vs Windows. E ha ottenuto una risposta concreta e obiettiva, con ulteriori approfondimenti concreti su quanto utile potrebbe essere lo scripting Unix su Windows.
Chernevik,

16
Perché è chiuso di nuovo? Qualcuno per favore modifica il titolo per dire "PowerShell vs Unix Shells sulla piattaforma Windows" per allontanare i troll dal trattarlo come "Windows vs Unix", che non lo è. Questa è una domanda perfettamente costruttiva - votata per riaprire.
x0n

3
L'operazione sta mescolando shell e strumenti. PowerShell ha il suo uso. Ma GNU è un progetto per portare liberamente gadget UNIX su altri sistemi operativi, incluso Windows. Ogni cosa nella lista op offre un'implementazione gnu in Windows. Accessibile da GnuWin32 o singoli siti. La BAT di Windows non è inutile, ha reindirizzamento, pipe e condizioni.
MeaCulpa,

Risposte:


783

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!


11
Grazie per la tua risposta. Penso che andrò avanti e imparerò PowerShell. Sembra potente da quello che ho visto finora, e sarò in grado di scrivere script più utili con esso al lavoro.
Andy White,

55
@Jeffrey: c'è una possibilità per un terminale migliore per Windows? Powershell è un potente linguaggio di scripting, ma il fatto che funzioni in cmd.exe lo rende molto più conveniente in modalità interattiva
sumek

47
Questa domanda "non costruttiva" ha generato la migliore intuizione che ho visto nel complesso "su Unix tutto è un file" mantra e perché Windows è diverso. Forse StackOverflow sarebbe meglio servire chiudendo discussioni non costruttive ?
Chernevik,

12
@sumek - Prova ConEmu; Lo uso da alcune settimane ed è piuttosto dolce: hanselman.com/blog/…
EZ Hart

4
Attenzione: a PowerShell non piace il piping dei dati binari. Quindi fai attenzione quando chiami i tuoi fidati strumenti Unix, semplicemente non fare cose come tar -c . | gzip > package.tar.gz direttamente in PowerShell, o soffrirai. Vedi brianreiter.org/2010/01/29/…
Interarticle,

123

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.


2
Il fatto è che il modello del provider è interessante solo perché il sistema operativo non utilizza il testo come mezzo di configurazione universale, quindi AVETE BISOGNO di questi provider. Con UNIX la maggior parte delle lingue ha API per toccare PAM, host e pacchetti, ma alla fine il testo sarà sempre lì.
Daishiman,

12
Il testo non è sempre il formato migliore per tutto (inizia con database e immagini raster). Ma penso che possiamo concordare di non essere d'accordo piuttosto che guerre di formato aperto.
Richard,

5
Powershell può usare qualsiasi oggetto nel framework .NET, questo non corrisponde alle capacità del dominio Perl? Inoltre, puoi scrivere cmdlet in C # ecc. Se desideri riusabilità
Chris S,

Confronto punto per punto. Ben fatto. Questa dovrebbe essere la risposta accettata. Il punto di forza di PowerShell risiede nelle sue basi .NET e nella facilità con cui è possibile estendere il sistema scrivendo nuovi Cmdlet o persino chiamando librerie di classi
Sau001

Un uso tipico di sed (penso) sarebbe:, sed 's/pattern/replacement/' fileche è approssimativamente gc file | %{$_ -replace 'pattern','replacement'}, e similmente per awk: awk 'BEGIN {} /pat1/ {action1} /pat2/ {action2} END {}' fileè approssimativamente{BEGIN {}; switch -r -c -file file { 'pat1' {action1} 'pat2' {action2}}; END{};}
Nathan Chappell

56

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.


1
Gli script unix funzionano perfettamente su Cygwin-Windows senza errori?
Pacerier,

@Pacerier Uso Cygwin e MinGW da 12 anni e ho avuto problemi sorprendentemente di rado. L'importante è che se qualcosa non funziona, è sempre possibile ricorrere agli strumenti di Windows o altro, i processi possono essere avviati nello stesso modo in cui qualsiasi altra shell li avvia.
Evgeni Sergeev,

4
Ok, la tua risposta è del 2011. Oggi PowerShell funziona anche su Linux. E - la mia opinione personale - bash è troppo antico. La sintassi è orribile e preferirei usare un linguaggio di scripting diverso. Oggi con Python standard sulla maggior parte delle distribuzioni di Linux non vedo alcun motivo per usare bash per gli script. Ti consiglierei di dare di nuovo un'occhiata a PowerShell perché è successo molto dal 2011.
Itmuckel,


33

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.


27
L'uso degli oggetti è un cambio di paradigma e richiede un po 'di tempo per abituarsi. Ma evita l'intero re-analisi in ogni fase in cui sono coinvolti dati strutturati (ad esempio, non è necessario garantire la delimitazione dei campi).
Richard,

16
@Andy White @Daishiman, posso capire dove c'è una curva di apprendimento con PowerShell, ma gli oggetti di piping possono essere molto più flessibili del testo di piping. @Richard è corretto. :)
Steven Murawski,

18
I produttori di automobili hanno avuto difficoltà a discutere anche con oltre 1000 anni di cavalli. Non sto cercando di essere irriverente. Basta sottolineare che il successo passato non rimuove il potenziale beneficio dell'innovazione.
EBGreen

12
@daishiman - Il vantaggio di Oggetti è che quando vuoi una proprietà, la chiedi - non devi analizzare, indovinare, lanciare. Non ho capito il tuo punto su "cosa succede quando gli oggetti non hanno metodi compatibili" - Potresti dirlo in un altro modo o fare un esempio del problema? Grazie.
Jeffrey Snover - MSFT,

13
@Daishiman - Ho capito. In pratica le persone hanno scoperto che questo non è un problema ma piuttosto un enorme vantaggio. Detto questo, posso vedere che se tu fossi un esperto analizzatore di testi, questa sarebbe una nuova abilità da imparare e all'inizio potrebbe sembrare non necessaria e imbarazzante. Ancora una volta, tutto ciò che aiuta è lo strumento giusto.
Jeffrey Snover - MSFT,

15

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.


2
Riesci a credere ai comandi criptici di quattro lettere che i nostri antenati sono stati costretti a usare?
Evgeni Sergeev,

4
@EvgeniSergeev Tutto quanto sopra sono disponibili per impostazione predefinita sls, sort, gu, gi, gc, rispettivamente. Nomi a lunga lettura che completano le schede e nomi brevi in ​​grado di scrivere in un sistema. Questo è un progresso facile da usare per te.
Tessellating Heckler,

Uno degli alias di Get-Contentè cat, quindi per quello non c'è alcuna differenza tra Cygwin / Unix e PowerShell. Sfortunatamente, nella maggior parte dei casi, nella documentazione di Microsoft per i cmdlet mancano informazioni sugli alias, ma un elenco di tutti gli alias viene generato utilizzandoGet-Alias una sessione di PowerShell. L'alias di "Get-Unique" è "gu", quindi è più breve di quello Cygwin / Unix!
Peter Mortensen,

13

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).


Ti chiedi "qualcuno sa qualcosa di meglio di: alias | where {$ _. ResolvedCommandName -eq" <command> "}?". Che ne dici di solo alias -Definition *property(o di qualsiasi altro modello)? Penso che il problema con la tua risposta sia che stai mescolando la shell e la console: ricorda che hai una scelta di console con diverse opzioni di modifica. Hanno deliberatamente lasciato la modifica della console DOS interrotta per incoraggiare le persone a utilizzare altre console come ISE.
Duncan,

A proposito, il tuo !!esempio può essere scritto in Powershell come (h -c 1) -replace '-1-','-2-' -replace '50','51' | iexma è più facile far scorrere la freccia e modificarlo per un singolo comando. Se vuoi farlo attraverso molti comandi, penso che Powershell avrebbe vinto. Per ripetere 10 comandi che terminano con il comando # 255 con le tue modifiche: (h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iexAnche la cronologia di Powershell ti consente di fare cose inaudite nelle shell di Linux; se ti chiedi retrospettivamente quanto tempo ha impiegato un comando per eseguire:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
Duncan,

@Duncan Per quanto riguarda il tuo commento riguardo la shell e la console, penso che questa sia solo una differenza fondamentale tra Bash e PS; vale a dire: Bash prevede di offrire una certa esperienza interattiva mentre PS "la lascia" a qualcos'altro. Non ho molta esperienza con la console ISE, ma da quanto posso ricordare, non ha nemmeno un'esperienza interattiva tremendamente ricca.
Eric Smith,

@Duncan, sì - buon punto sulla capacità di PS di fornire trucchi storici intelligenti.
Eric Smith,

@Duncan ... ma nonostante la tua affermazione che alcune cose sono inaudite nelle shell Linux:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
Eric Smith

8

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.


1
Esiste un progetto open source "Pash" che ti consente di eseguire PowerShell su altre piattaforme tramite Mono. tinyurl.com/6dyoso
John D. Cook,

Whoa! Grazie per il consiglio; Non vedo l'ora di provarlo
yalestar,

6

Se ti piacciono gli script di shell, adorerai PowerShell!

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


8
Adoro gli script di shell e tollero PowerShell. I suoi comandi e la sintassi sono atroci. Comandi e opzioni orribilmente lunghi senza alcun utile completamento dei comandi. O se c'è non l'ho trovato. Troppe funzioni racchiuse in singoli comandi che dovrebbero essere separati. Strana variabile e sintassi di escape che solo un programmatore batch DOS può apprezzare.
Zan Lynx,

8
@Zan Lynx - Hai ragione sul non aver trovato cose. Tutti i comandi hanno alias e molti di essi corrispondono a comandi DOS e UNIX (ps, dir, rm, ls, kill, history, man, cat, clear ecc.) I nomi sono lunghi in modo che abbiano un nome significativo. Ottimo per gli script: aiuta quando una nuova persona deve usarlo e mantenerlo. Esiste un'espansione della scheda per cmdlet, funzioni, variabili, percorso, parametri ecc. Gran parte della sintassi proviene da shell Unix e di quale sintassi di escape stai parlando? `` non viene utilizzato per la fuga poiché è il separatore di percorso in Windows.
manojlds,

3
@Zan Lynx - I tuoi argomenti non sono validi. Per interrompere l'interpretazione delle variabili, utilizzare '(virgolette singole). Per le doppie virgolette, lo stesso, usa write-output 'this is a "test"'. La domanda che stai ponendo è per Regex e la fuga per regex è valida ovunque. Powershell ha anche stringhe Here-Strings / verbatim. Anche Java non ha questi! Prova a scappare da regex in Java. E a volte non usi letteralpath. Usi quando è necessario. LiteralPath tratta i caratteri jolly alla lettera e non li espande. Lo usi quando hai i tuoi file. Ti dà più opzioni.
manojlds,

3
@manojlds: Rispetto alla shell bash, Powershell è pieno di incoerenze che non hanno senso e sono solo confuse. In bash usi lo stesso carattere di escape ovunque e i percorsi dei file vengono salvati esattamente come le stringhe. Non è necessario un parametro speciale per questo. Se si espande una variabile che contiene caratteri speciali, la si mette tra virgolette doppie e il contenuto è sicuro, non è necessario chiamare una funzione per fuggire nuovamente.
Zan Lynx,

5
@Zan Lynx - Non ci sono incoerenze. Anche le write-output "this is a `"test`""opere. Basta usare `invece di `\`. regex :: escape esiste per aiutarti in modo da non perdere cose di fuga. Non è necessario usarlo. Stai pensando che le opzioni aggiuntive che sono lì per aiutarti e prevenire errori sono incoerenze.
manojlds,

6

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.


6

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 .


Sì, immagino che quando parlo della "shell" di Unix mi riferisco anche a tutte le normali utility fornite con Unix, come grep, awk, ecc. Mi chiedo solo se PowerShell offre utility simili -la scatola.
Andy White,

3
Powershell non è "solo una shell". È un linguaggio di scripting. Mi chiedo in che modo non sia paragonabile al perl? Ammetto che non è così maturo, ma oltre a ciò non vedo la disparità.
EBGreen

@EBGreen, cosa intendi esattamente con questo commento? Concordo sul fatto che qualsiasi linguaggio di shell o scripting sia intrinsecamente simile, ma mi chiedevo di più sulle capacità specifiche di PowerShell rispetto a bash / perl / altri linguaggi di shell / scripting unix.
Andy White,

2
Powershell ha una gamma incredibilmente ampia di funzioni. È - Una shell interattiva e compostabile - Un ricco linguaggio di script interattivo - Un linguaggio di programmazione Ha anche un ricco set di funzioni di utilità OO e tesxt (cioè equivalenti a grep / awk / etc).
Jeffrey Snover - MSFT,

1
@Andy - Ho capito Devio dire che PowerShell non è potente come Perl. Non credo sia vero e mi chiedevo solo perché pensasse che fosse così.
EBGreen

4

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.


4

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, ModificaSegna ancora l'unico modo per copiare le informazioni e copiarle solo sotto forma di blocchi rettangolari di spazio terminale visibile. e ModificaSegna 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.


Attiva la modalità QuickEdit? Seleziona e premi Invio per copiare, ctrl-v per incollare, non più Modifica-> Seleziona o Modifica-> Incolla. Nelle preferenze, imposta la posizione della finestra e deseleziona "lascia finestra di posizione del sistema". Il completamento della scheda non sta solo completando i percorsi del filesystem, sta anche completando nomi di variabili, nomi di comandi, proprietà dell'oggetto, potresti essere in procinto di digitare .o [accedere a una proprietà o indice, quindi non può semplicemente aggiungere un separatore di percorso alla fine. Quale PowerShell wget, esattamente? Quale PowerShell POSIX? Non sta cercando di portare gli strumenti di GNU su Windows, né di essere compatibile con Bash.
Tessellating Heckler,

Sì, lo so che non sta cercando di essere pessimo. Mi sono trattenuto dal dirlo nel post originale. Direi quale w diventa binario ma non esiste un comando "quale" in Power Shell :( non ricordo dove comprare ho letto potere Shell doveva essere compatibile POSIX
ThorSummoner

5
ri: "no what" -> (get-command wg*.exe).Path. Ri: bash completamento e readline -> leeholmes.com/blog/2012/09/13/… che conduce a github.com/lzybkr/PSReadLine
TessellatingHeckler

2

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.



1

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.


0

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


16
Penso che stai confondendo Windows Scripting Host (WSH) con PowerShell. Sono totalmente diversi.
Erik Funkenbusch,

3
Ad esempio, se si desidera eliminare tutti i file che finiscono in .TMN è possibile emettere questo comando get-childitem c: \ -include * .TMN -recurse | foreach ($ _) {rimuovi elemento $ _. nome completo}
Erik Funkenbusch,

@Mystere: ho provato questo, e non sembra funzionare. Dopo un po 'di sciocchezza, sembra che * .tmn sia quello di cui hai bisogno (anziché solo .tmn)
redtuna,

5
Non potrei essere più in disaccordo con rispetto, e non sono affatto un ragazzo di Windows. Trovo PS molto più facile da scrivere che bash. PS è più coerente. Con Bash, qualsiasi utility di console che invochi ha una sua sintassi e un comportamento unico e la stessa sintassi bash è piuttosto criptica. PS è molto più robusto con funzionalità di linguaggio come funzioni anonime, (blocchi di script), convalida dei parametri, funzioni avanzate ecc. Più concetti di moduli per la portabilità e molte altre funzionalità. Principalmente, tuttavia, il motivo principale è la cosa che senti sempre su PS, il testo di briscola degli oggetti. Bash è comunque più veloce.
user2233949


0

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 ...


Penso che potresti perdere gli obiettivi di progettazione delle shell Unix. Non bussare a PowerShell (vorrei saperne di più da solo) ma devi capire gli strumenti Unix per fare una dichiarazione del genere.
Jé Queue,

2
@Xepoch - No, penso che ti stiano perdendo gli obiettivi di progettazione di PowerShell. PowerShell può fare tutto ciò che le shell Unix possono fare nello stesso modo in cui lo fanno. Tuttavia, la vera potenza arriva quando si utilizza il sistema di piping degli oggetti di PS piuttosto che analizzare semplicemente l'output del testo. Quindi, PowerShell può fare esattamente ciò che può fare bash o korn, ma non può fare ciò che PowerShell può fare.
Erik Funkenbusch,

3
Semplicemente non conosco abbastanza PowerShell per darti una critica al riguardo, ma come sai chiaramente gli obiettivi delle shell Unix non sono necessariamente una sostituzione completa degli strumenti esterni, ma piuttosto le strutture di controllo intorno ad esso. Ancora una volta non posso in questo momento confrontare né contrastare, ma elevare PowerShell perché ha più built-in non è necessariamente il vantaggio delle shell Unix.
Jé Queue,

@Xepoch - Il punto è che puoi scegliere in che modo vuoi farlo. Puoi usare tutta la bontà della shell integrata, oppure puoi ignorarla e farlo come fa Unix. È la vostra scelta. E la scelta è buona, vero?
Erik Funkenbusch,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.