PowerShell est-il prêt à remplacer mon shell Cygwin sous Windows? [fermé]

Je me demande si je devrais apprendre PowerShell, ou simplement m'en tenir aux scripts Cygwin / Perl / shell Unix, etc.

L'avantage de PowerShell serait que les scripts pourraient être plus facilement utilisés par les coéquipiers qui n'ont pas Cygwin; cependant, je ne sais pas si j'écrirais vraiment autant de scripts à usage général, ou si les gens les utiliseraient même.

Les scripts Unix sont si puissants, PowerShell se rapproche-t-il suffisamment pour justifier le basculement?

Voici certaines des choses spécifiques (ou équivalentes) que je rechercherais dans PowerShell:

• grep
• Trier
• uniq
• Perl (dans quelle mesure PowerShell se rapproche-t-il des capacités de Perl?)
• AWK
• sed
• file (la commande qui donne des informations sur le fichier)
• etc.

Les outils ne sont que des outils.
Ils aident ou non.
Vous avez besoin d'aide ou non.

Si vous connaissez Unix et que ces outils font ce que vous devez faire sous Windows - alors vous êtes un gars heureux et il n'est pas nécessaire d'apprendre PowerShell (sauf si vous voulez explorer).

Mon intention initiale était d'inclure un ensemble d'outils Unix dans Windows et d'en finir (un certain nombre d'entre nous dans l'équipe ont des antécédents Unix profonds et une bonne dose de respect pour cette communauté.)

Ce que j'ai trouvé, c'est que cela n'a pas vraiment aidé beaucoup. La raison en est que AWK / grep / sed ne fonctionne pas contre COM , WMI , ADSI , le registre, le magasin de certificats, etc., etc.

En d'autres termes, UNIX est un écosystème entier réglé automatiquement autour de fichiers texte. En tant que tels, les outils de traitement de texte sont des outils de gestion efficaces. Windows est un écosystème complètement différent auto-réglé autour des API et des objets. C'est pourquoi nous avons inventé PowerShell.

Je pense que vous constaterez qu'il y aura de nombreuses occasions où le traitement de texte ne vous donnera pas ce que vous voulez sous Windows. À ce stade, vous voudrez prendre PowerShell. REMARQUE - ce n'est pas un accord tout ou rien. Dans PowerShell, vous pouvez appeler vos outils Unix (et utiliser leur processus de texte ou le traitement de texte de PowerShell). Vous pouvez également appeler PowerShell à partir de vos outils Unix et obtenir du texte.

Encore une fois - il n'y a pas de religion ici - notre objectif est de vous donner les outils dont vous avez besoin pour réussir. C'est pourquoi nous sommes si passionnés par la rétroaction. Faites-nous savoir où nous tombons sur le chantier ou si vous n'avez pas un outil dont vous avez besoin et nous le mettrons sur la liste et y arriverons.

En toute honnêteté, nous nous sortons d'un trou de 30 ans, donc cela va prendre un certain temps. Cela dit, si vous prenez la version bêta de Windows Server 2008 / R2 et / ou les bêtas de nos produits serveurs, je pense que vous serez choqué de la rapidité avec laquelle ce trou se comble.

En ce qui concerne l'utilisation - nous avons eu plus de 3,5 millions de téléchargements à ce jour. Cela n'inclut pas les personnes qui l'utilisent dans Windows Server 2008, car il est inclus en tant que composant facultatif et n'a pas besoin d'être téléchargé.

V2 sera livré dans toutes les versions de Windows. Il sera activé par défaut pour toutes les éditions, sauf Server core où il s'agit d'un composant facultatif. Peu de temps après la livraison de Windows 7 / Windows Server 2008 R2, nous rendrons V2 disponible sur toutes les plates-formes, Windows XP et supérieur. En d'autres termes - votre investissement dans l'apprentissage sera applicable à un très grand nombre de machines / environnements.

Un dernier commentaire. Si / quand vous commencez à apprendre PowerShell, je pense que vous serez plutôt content. Une grande partie de la conception est fortement influencée par nos arrière-plans Unix, donc bien que nous soyons assez différents, vous le prendrez très rapidement (après avoir fini de cusser que ce n'est pas Unix :-)).

Nous savons que les gens ont un budget très limité pour l'apprentissage - c'est pourquoi nous sommes très intransigeants sur la cohérence. Vous allez apprendre quelque chose, puis vous l'utiliserez encore et encore.

Expérience! Prendre plaisir! Engager!

grep

Select-StringL'applet de commande et l' -matchopérateur fonctionnent avec des expressions rationnelles. Vous pouvez également utiliser directement la prise en charge des expressions régulières de .NET pour des fonctionnalités plus avancées.

Trier

Sort-Objectest plus puissant (que je me souviens de * nix sort). Autoriser le tri à plusieurs niveaux sur des expressions arbitraires. Ici, la maintenance par PowerShell du type sous-jacent aide; Par exemple, une DateTimepropriété sera triée en tant que DateTimesans avoir à assurer la mise en forme dans un format triable.

uniq

Select-Object -Unique

Perl (dans quelle mesure PowerShell se rapproche-t-il des capacités Perl?)

Pour ce qui est de l'étendue des bibliothèques de support spécifiques à un domaine de Perl: nulle part proche (pour l'instant).

Pour la programmation générale, PowerShell est certainement plus cohérent et cohérent, et plus facile à étendre. La seule lacune pour la fusion de texte est quelque chose d'équivalent à l' ..opérateur de Perl .

AWK

Cela fait assez longtemps que j'utilise AWK (ça doit être> 18 ans, car plus tard, je viens d'utiliser Perl), donc je ne peux pas vraiment commenter.

sed

[Voir au dessus]

file (la commande qui donne des informations sur le fichier)

La force de PowerShell ici n'est pas tant de ce qu'il peut faire avec les objets du système de fichiers (et il obtient des informations complètes ici, des dirretours FileInfoou des FolderInfoobjets selon le cas), c'est qu'il s'agit du modèle de fournisseur complet.

Vous pouvez traiter le registre, le magasin de certificats, SQL Server, le cache RSS d'Internet Explorer, etc. comme un espace objet navigable par les mêmes applets de commande que le système de fichiers.

PowerShell est définitivement la voie à suivre sous Windows. Microsoft en a fait une partie de leurs exigences pour les futurs produits non domestiques. D'où un support riche dans Exchange, un support dans SQL Server. Cela ne fera que s'étendre.

Un exemple récent de ceci est le TFS PowerToys. De nombreuses opérations du client TFS sont effectuées sans avoir à démarrer tf.exe à chaque fois (ce qui nécessite une nouvelle connexion au serveur TFS, etc.) et il est notamment plus facile de traiter ensuite les données. En plus de permettre un large accès à l'ensemble de l'API client TFS à un niveau de détail supérieur à celui exposé dans les deux Team Explorer de TF.exe.

En tant que personne dont la carrière s'est concentrée sur le développement d'entreprise Windows de 1997 à 2010, la réponse évidente serait PowerShell pour toutes les bonnes raisons données précédemment (par exemple, cela fait partie de la stratégie d'entreprise de Microsoft; il s'intègre bien avec Windows / COM / .NET; et l'utilisation d'objets au lieu de fichiers permet d'obtenir un modèle de codage "plus riche"). Pour cette raison, j'utilisais et promouvais PowerShell depuis environ deux ans, avec la conviction expresse que je suivais le "Word of Bill".

Cependant, en tant que pragmatique, je ne suis plus sûr que PowerShell soit une excellente réponse. Bien qu'il s'agisse d'un excellent outil Windows et qu'il constitue une étape indispensable pour combler le trou historique qu'est la ligne de commande Windows, alors que nous observons tous l'adhérence de Microsoft sur le glissement de l'informatique grand public, il semble de plus en plus probable que Microsoft ait une bataille énorme à faire pour conserver son système d'exploitation comme important pour l'entreprise de demain.

En effet, étant donné que je trouve que mon travail est de plus en plus dans des environnements hétérogènes, je trouve qu'il est beaucoup plus utile d'utiliser des scripts Bash pour le moment, car ils fonctionnent non seulement sur Linux, Solaris et Mac OS X, mais ils fonctionnent également - avec le l'aide de Cygwin — sur Windows.

Donc, si vous croyez que l'avenir du système d'exploitation est marchandisé plutôt que monopolisé, il semble logique d'opter pour une stratégie d'outil de développement agile qui s'éloigne des outils propriétaires lorsque cela est possible. Si toutefois vous voyez que votre avenir est dominé par tout ce qui est Redmond, optez pour PowerShell.

J'ai utilisé un peu de PowerShell pour l'automatisation des scripts. Bien qu'il soit très agréable que l'environnement semble avoir été pensé beaucoup plus que les shells Unix, dans la pratique, l'utilisation d'objets au lieu de flux de texte est beaucoup plus maladroite, et beaucoup des fonctionnalités Unix qui ont été développées au cours des 30 dernières années. il manque encore des années.

Cygwin est toujours mon environnement de script de choix pour les hôtes Windows. Il bat certainement les alternatives en termes de faire avancer les choses.

Il y a beaucoup de bonnes réponses ici, et voici mon avis. PowerShell est prêt si vous l'êtes ... Exemples:

grep = " Select-String -Pattern "

sort = "Sort-Object"

uniq = " Get-Unique "

file = " Get-Item "

cat = " Get-Content "

Perl / AWK / Sed ne sont pas des commandes, mais des utilitaires donc difficiles à comparer, mais vous pouvez presque tout faire dans PowerShell.

Je n'ai commencé à m'essayer à PowerShell que récemment avec sérieux. Bien que depuis sept ans, je travaille dans un environnement presque exclusivement basé sur Windows, je viens d'un arrière-plan Unix et je me retrouve constamment à "Unix-fy" mon expérience d'interaction sur Windows. C'est pour le moins frustrant.

Il est juste de comparer PowerShell à quelque chose comme Bash , tcsh ou zsh car les utilitaires comme grep , sed , awk , find , etc. ne font pas à proprement parler partie du shell; cependant, ils feront toujours partie de tout environnement Unix. Cela dit, une commande PowerShell comme Select-String a une fonction très similaire à grep et est regroupée en tant que module principal dans PowerShell ... de sorte que les lignes peuvent être un peu floues.

Je pense que l'élément clé est la culture et le fait que les ensembles d'outils respectifs incarneront leurs cultures respectives:

• Unix est une culture textuelle basée sur des fichiers (en général, non Unicode) . Les fichiers de configuration sont presque exclusivement des fichiers texte . Windows, en revanche, a toujours été beaucoup plus structuré en ce qui concerne les formats de configuration - les configurations sont généralement conservées dans des bases de données propriétaires (par exemple, le registre Windows) qui nécessitent des outils spécialisés pour leur gestion.

• L'interface administrative Unix (et, depuis de nombreuses années, le développement) est traditionnellement la ligne de commande et le terminal virtuel. Windows a commencé comme une interface graphique et les fonctions administratives n'ont commencé que récemment à être exclusivement basées sur une interface graphique. Nous pouvons nous attendre à ce que l'expérience Unix sur la ligne de commande soit plus riche et plus mature compte tenu de son avance significative sur PowerShell, et mon expérience correspond à cela. À ce sujet, selon mon expérience:

  • L'expérience administrative Unix vise à faciliter les choses en un minimum de touches; cela est probablement dû à la situation historique de devoir administrer un serveur sur une connexion d'accès à distance lente à 9600 bauds. Maintenant, PowerShell a des alias qui permettent de contourner la norme Verb-Noun plutôt verbeuse , mais apprendre à connaître ces alias est un peu pénible (quiconque connaît quelque chose de mieux que alias | where {$_.ResolvedCommandName -eq "<command>"}:?).

    Un exemple de la manière riche dont l'histoire peut être manipulée:

    iptablesles commandes sont souvent de longue haleine et les répéter avec de légères différences serait pénible si ce n'était pas pour l'une des nombreuses fonctionnalités intéressantes de la manipulation de l'historique intégrée à Bash , donc insérer une règle iptables comme celle-ci:

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

    une deuxième fois pour un autre appareil photo (" camera-2"), est juste un cas d'émission:

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

    ce qui signifie "exécuter la commande précédente, mais remplacer -1-par -2-et 50par 51.

  • L'expérience Unix est optimisée pour les dactylographes; on peut à peu près tout faire sans quitter la position «maison». Par exemple, dans Bash , en utilisant les raccourcis clavier Emacs (oui, Bash prend également en charge les liaisons vi ), parcourir l'historique se fait en utilisant Ctrl-Pet Ctrl-Ntout en se déplaçant vers le début et la fin d'une ligne se fait en utilisant Ctrl-Aet Ctrl-Erespectivement ... et c'est définitivement ne s'arrête pas là. Essayez même la navigation la plus simple dans la console PowerShell sans bouger de la position d'origine et vous avez des ennuis.

  • Des choses simples comme la pagination polyvalente (à tout le moins ) sur Unix ne semblent pas être disponibles dès le départ dans PowerShell, ce qui est un peu frustrant, et une riche expérience d'éditeur n'existe pas non plus. Bien sûr, on peut toujours télécharger des outils tiers qui combleront ces lacunes, mais ce serait bien si ces choses étaient "là" comme si elles étaient à peu près toutes les saveurs d'Unix.

• La culture Windows, au moins en termes d'API système, est largement influencée par les cadres de prise en charge, à savoir., COM et .NET , qui sont tous deux très structurés et basés sur des objets. D'un autre côté, l'accès aux API Unix se fait traditionnellement via une interface de fichier ( /devet /proc) ou des appels de bibliothèque de style C (non orientés objet). Il n'est donc pas surprenant que les expériences de script correspondent à leurs paradigmes OS respectifs. PowerShell est par nature structuré (tout est un objet) et basé sur des fichiers Bash et amis. L'API structurée à la disposition d'un programmeur PowerShell est vaste (correspondant essentiellement à l'immensité de l'ensemble existant d' interfaces COM et .NET standard).

En bref, bien que les capacités de script de PowerShell soient sans doute plus puissantes que Bash (en particulier lorsque vous considérez la disponibilité du .NET BCL ), l' expérience interactive est considérablement plus faible, en particulier si vous y arrivez à partir d'un clavier entièrement piloté , perspective basée sur la console (comme le sont de nombreuses têtes Unix).

Je ne suis en aucun cas un utilisateur PowerShell très expérimenté, mais le peu auquel j'ai été exposé m'a beaucoup impressionné. Vous pouvez chaîner les applets de commande intégrées pour faire à peu près tout ce que vous pouvez faire à l'invite Unix, et il y a des avantages supplémentaires pour faire des choses comme l'exportation vers CSV, des tables HTML et pour des types de travaux d'administration système plus approfondis .

Et si vous avez vraiment besoin de quelque chose comme sed , il y a toujours UnixUtils ou GnuWin32 , que vous pouvez intégrer assez facilement à PowerShell.

En tant qu'utilisateur Unix de longue date, j'ai cependant eu un peu de mal à m'habituer au schéma de dénomination des commandes, et j'en aurais certainement bénéficié davantage si j'avais su plus de .NET.

Donc, pour l'essentiel, je dis que cela vaut la peine de l'apprendre si le fait que Windows ne pose pas de problème.

Si vous aimez les scripts shell, vous allez adorer PowerShell!

Commencez par Une visite guidée de Microsoft Command Shell (Ars Technica).

Comme mes récentes expériences m'ont conduit dans les profondeurs des appels PowerShell et .NET, je dois dire que PowerShell peut remplacer le shell Cygwin et Unix.

Je ne suis pas sûr de Perl, mais étant donné que PowerShell et Perl sont tous les deux des langages de programmation Turing, je donne aussi un oui au remplacement de Perl.

Une chose que PowerShell a au-dessus de Cygwin et de Bash ordinaire sous * nix, c'est sa capacité à effectuer des appels DLL en bac à sable, en manipulant le système d'exploitation via des appels API directs, des méthodes WMI et même des objets COM. Que diriez-vous de lancer Internet Explorer via le code, puis de faire ce que vous voulez avec son document affiché, en émulant efficacement un back-end pour un serveur Web?

Que diriez-vous de collecter des données à partir de serveurs SQL et d'autres fournisseurs de données, de les analyser et d'exporter au format CSV, des messages électroniques, du texte et en fait tout type de formats de fichiers existants et non existants? (Avec des compétences appropriées pour créer un fichier valide à partir des données reçues, bien sûr, mais le CSV est facilement disponible).

De plus, une sécurité supplémentaire est disponible via des applets de commande et des scripts signés, des stratégies de groupe et des stratégies d'exécution qui empêchent l'exécution de code malveillant sur votre système même si vous les exécutez en tant qu'administrateur.

À propos des commandes implémentées - la réponse de Richard les répertorie et la capacité de PowerShell à déjà émuler leurs fonctionnalités.

La question de savoir si PowerShell est solide pour justifier le basculement - c'est plus une question de préférence personnelle, bien que de plus en plus de services Windows fournissent des applets de commande PowerShell pour les contrôler, ne pas utiliser PowerShell avec ces services présents est considéré comme un obstacle. (Le serveur Hyper-V est le principal service de ce type, et il offre également la possibilité de faire plus avec les applets de commande PowerShell qu'avec l'interface graphique!)

Cette réponse a probablement cinq ans de retard, mais quand même, si quelqu'un effectue des tâches administratives ou des scripts généraux sur Windows, il doit absolument essayer d'exploiter PowerShell à ses fins.

Lorsque vous comparez PowerShell à la combinaison Cygwin / Perl / Shell, sachez que PowerShell ne représente que la partie "Shell" de cette combinaison.

Vous pouvez cependant appeler n'importe quelle commande à partir de PowerShell comme vous le faites à partir de cmd.exe ou Cygwin. Il ne réimplémente pas les fonctions spécifiées et n'est certainement pas comparable à Perl.

C'est "juste" un shell, mais cela facilite la programmation en fournissant une interface confortable à l'univers .NET.

Gardez également à l'esprit que PowerShell nécessite Windows XP, Windows Server 2003 ou supérieur, ce qui peut poser problème en fonction de votre infrastructure informatique.

Mise à jour:

Je ne savais pas quel genre de débat philosophique déclencherait ma réponse.

J'ai posté ma réponse dans le contexte de la question: comparer PowerShell à Cygwin et Perl et Bash.

PowerShell est un shell, car il ne fait aucune différence syntaxique entre les commandes intégrées, les commandlets, les fonctions utilisateur et les commandes externes (.exe, .bat, .cmd). Seule l'invocation de méthodes .NET diffère par l'ajout d'un espace de noms ou d'un objet dans l'appel.

Sa programmabilité dérive du framework .NET, et non de quelque chose de spécifique au "langage" PowerShell.

Je dirais que je crois que PowerShell est un "langage de script" dès que Bugzilla ou MediaWiki sont implémentés en tant que scripts PowerShell s'exécutant sur un serveur Web;)

D'ici là, profitez des comparaisons .

Les applets de commande dans PowerShell sont très agréables et fonctionnent de manière fiable. Leur orienté objet me plaît beaucoup depuis que je suis développeur Java / C #, mais ce n'est pas du tout un ensemble complet. Comme il est orienté objet, il manque une grande partie de la maturité du flux de texte de l'ensemble d'outils POSIX ( awket sedpour n'en nommer que quelques-uns).

La meilleure réponse que j'ai trouvée au dilemme d'aimer les techniques d'OO et d'aimer la maturité des outils POSIX est d'utiliser les deux! Un grand aspect de PowerShell est qu'il fait un excellent travail en redirigeant des objets vers des flux standard. Par défaut, PowerShell utilise un pipeline d'objets pour transporter ses objets. Ce ne sont pas les flux standard (sortie standard, erreur standard et entrée standard). Lorsque PowerShell doit passer la sortie à un processus standard qui n'a pas de pipeline d'objets, il convertit d'abord les objets en un flux de texte. Puisqu'il le fait si bien, PowerShell est un excellent endroit pour héberger les outils POSIX!

Le meilleur ensemble d'outils POSIX est GnuWin32 . L'installation prend plus de 5 secondes, mais cela en vaut la peine, et pour autant que je sache, cela ne modifie pas votre système (registre, c:\windows\*dossiers, etc.) sauf la copie de fichiers dans les répertoires que vous spécifiez. C'est très agréable car si vous placez les outils dans un répertoire partagé, de nombreuses personnes peuvent y accéder simultanément.

Instructions d'installation de GnuWin32

Téléchargez et exécutez l' exe (il provient du site SourceForge ) en le pointant vers un répertoire approprié (j'utiliserai C:\bin). Il y créera un GetGnuWin32répertoire dans lequel vous exécuterez download.bat, puis install.bat(sans paramètres), après quoi, il y aura un C:\bin\GetGnuWin32\gnuwin32\binrépertoire qui est le dossier le plus utile qui ait jamais existé sur une machine Windows. Ajoutez ce répertoire à votre chemin et vous êtes prêt à partir.

TL; DR - Je ne déteste pas Windows ou PowerShell. Je ne peux rien faire dans Windows ou sur PowerShell.

Personnellement, je trouve toujours PowerShell décevant au mieux.

• la complétion de tabulation des chemins de répertoire ne se compose pas, obligeant l'utilisateur à entrer un séparateur de chemin après chaque complétion de nom.
• J'ai toujours l'impression que Windows n'a même pas le concept d'un chemin ou de ce qu'est un chemin, sans indicateur d'accueil de l'utilisateur accessible à ~/court de certains@environment://somejibberish/%user_home%

• NTFS est toujours un gâchis et le sera apparemment toujours. Bonne chance pour naviguer.

• interface cmd-esque, Le dinosaure cmd.exe est toujours visible dans PowerShell, Édition → Marquer étant toujours le seul moyen de copier des informations, et de copier uniquement sous la forme de blocs rectangulaires d'espace terminal visible. et Édition → Marquer étant toujours le seul moyen de coller des chaînes dans le terminal.

• Le peindre en bleu ne le rend pas plus attrayant. Je n'ai pas d'objection à ce que les développeurs Microsoft aient un goût pour la couleur.

• Windows s'ouvre toujours dans le coin supérieur gauche de l'écran. Pour quelqu'un qui utilise des barres de tâches verticales, cela est incroyablement ennuyeux, d'autant plus que la barre des tâches de Windows couvrira le seul coin de la fenêtre qui donne accès à la fonctionnalité de copier / coller.

Je ne peux pas parler beaucoup en raison des outils que Windows inclut. Étant donné qu'il existe un ensemble complet d'outils CLI open source et sous licence gratuite, et PowerShell est livré avec, à ma connaissance, aucun d'eux n'est une déception totale.

• PowerShell wgetprend des arguments apparemment incomparables à GNU wget. Merci, lueur d'espoir inutilement portable.
• PowerShell POSIX n'est pas compatible avec Bash, en particulier l' &&opérateur n'est pas géré, ce qui rend la commande conditionnelle la plus simple qui suit.

Je ne connais pas d'homme; Je lui ai donné un coup de feu, je l'ai vraiment fait; J'essaie toujours de lui donner un coup dans l'espoir que la prochaine fois que je l'ouvrirai, ce sera moins inutile. Je ne peux rien faire dans PowerShell, et je peux à peine faire des choses avec un vrai projet pour apporter des outils GNU à Windows.

MySysGit me donne l'invite dinosaur cmd.exe avec quelques outils GNU, et c'est toujours très décevant, mais au final, l'achèvement du chemin fonctionne. Et la commande Git s'exécutera dans Git Bash.

Mintty pour MySysGit donne l'interface Cygwin sur l'environnement de mysysgit, faisant copier et coller une chose (sélectionnez pour copier (souris), Shift+ Inspour coller, comment moderne ...). Cependant, des choses comme celles-là git pushsont cassées à Mintty.

Je ne veux pas me plaindre, mais je vois toujours d'énormes problèmes avec la convivialité de la ligne de commande sous Windows même avec des outils comme Cygwin.

PS: ce n'est pas parce que quelque chose peut être fait dans PowerShell qu'il est utilisable . L'utilisabilité est plus profonde que la capacité et c'est ce sur quoi j'ai tendance à me concentrer lorsque j'essaie d'utiliser un produit en tant que consommateur.

Je n'ai pas vu que le PowerShell avait vraiment décollé, du moins pas encore. Il ne vaut donc pas la peine de l'apprendre à moins que les autres membres de votre équipe le sachent déjà.

Pour votre situation difficile, vous pourriez être mieux avec un langage de script que d'autres pourraient obtenir, Perl comme vous l'avez mentionné, ou d'autres comme Ruby ou Python.

Je pense que cela dépend en grande partie de ce que vous devez faire. Personnellement, j'utilise Python pour mes propres scripts personnels, mais je sais quand je commence à écrire quelque chose que je ne pourrai jamais le transmettre - alors j'essaie de ne rien faire de trop révolutionnaire.

Pourquoi ne pas utiliser les deux? Appelez les scripts PowerShell dans Cygwin comme tout autre script interprété comme Perl, etc.

Je le fais suffisamment pour avoir écrit https://bitbucket.org/jbianchi/powershell pour un wrapper Bash pour appeler powershell.exe dans Cygwin. Il peut être utilisé comme un shebang comme première ligne d'un script powershell.exe .ps1 (car PowerShell utilise également "#" comme commentaire). Voir https://bitbucket.org/jbianchi/powershell/wiki/Home pour des exemples

En quelques lignes, Cygwin et PowerShell sont des outils différents, mais si Cygwin est installé, vous pouvez exécuter les exécutables Cygwin dans une session PowerShell. Je me suis tellement habitué à PowerShell que maintenant je n'utilise plus grep, sort, awk, etc. Il existe à peu près des alternatives intégrées dans PowerShell, et sinon vous pouvez trouver une applet de commande là-bas.

L'outil principal que je me retrouve à utiliser est ssh.exe, mais dans une session PowerShell.

Cela fonctionne très bien.

J'ai trouvé que la programmation PowerShell n'en valait pas la peine.

J'ai plusieurs années d'expérience avec les scripts shell sous Unix, mais j'ai trouvé qu'il était extrêmement difficile de faire quoi que ce soit avec PowerShell.

Il semble que de nombreuses fonctions nécessitent que vous interrogiez l'interface de gestion Windows et émettez des commandes de type SQL pour obtenir les informations dont vous avez besoin.

Par exemple, je voulais écrire un script pour supprimer tous les fichiers avec un suffixe spécifique d'une arborescence de répertoires. Sous Unix, ce serait simple ...

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

Après quelques heures dicking autour avec Scripting.FileSystemObjectet WScript.Shellet l' émission "SELECT * FROM Win32_ShortcutFile où Drive = '" & drive & " 'AND Path ='" & SearchFolder & "'", j'ai finalement abandonné et installé pour l' explorateur Windows Search commandement et faites-le simplement manuellement. Il y a probablement un moyen de faire ce que je voulais, mais je n'ai rien vu d'évident et tous les exemples sur le site MSDN étaient si triviaux qu'ils étaient sans valeur.

EDIT Heh, bien sûr, dès que j'ai écrit cela, j'ai fouillé un peu plus et j'ai trouvé ce qui me manquait: l' -recurseoption de la commande remove-item est défectueuse (révélée si vous utilisez get-help remove-item -detailed).

J'avais essayé "remove-item -filter '* .xyz' -recurse" et cela ne fonctionnait pas, alors j'ai abandonné.

Il s'avère que vous devez utiliser get-childitem -filter '*.xyz' -recurse | remove-item

Vous pouvez également essayer d'exécuter des scripts Bash sur Windows à l'aide de BashWin sur https://github.com/skanga/BashWin .

PowerShell est très puissant, plus puissant que les fonctions intégrées standard des shells Unix (mais uniquement parce qu'il inclut une grande partie des fonctionnalités généralement décortiquées en sous-programmes). En outre, considérez que vous pouvez écrire des applets dans toutes les langues .NET, y compris IronPython , IronRuby , PerlNet, etc .. ou vous pouvez simplement appeler vos commandes Cygwin de PowerShell, en ignorant toutes les fonctionnalités supplémentaires et cela fonctionnera de façon similaire à Bash, KornShell , ou peu importe...