PowerShell est-il prêt à remplacer mon shell Cygwin sous Windows?
Je suis en train de me demander si je devrais apprendre PowerShell, ou simplement rester avec Cygwin /scripts Perl/scripts Unix Shell, etc.
L'avantage de PowerShell serait que les scripts pourraient être plus facilement utilisés par des coéquipiers n'ayant 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 est-il suffisamment proche pour justifier un basculement?
Voici quelques éléments spécifiques (ou équivalents) que je rechercherais dans PowerShell:
Les outils ne sont que des outils.
Ils aident ou ils n'aiment pas.
Vous avez besoin d’aide ou pas.
Si vous connaissez Unix et que ces outils font ce que vous avez besoin de faire sous Windows, alors vous êtes un gars heureux et vous n'avez pas besoin d'apprendre PowerShell (à moins que vous ne souhaitiez explorer).
Mon intention initiale était d'inclure un ensemble d'outils Unix dans Windows et d'en finir avec cela (un certain nombre d'entre nous dans l'équipe possédons une expérience profonde de Unix et une bonne dose de respect pour cette communauté.) Ce que j'ai découvert est que cela ne vraiment aider 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 complet auto-réglé sur des 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-ajusté autour d’API et d’objets. C'est pourquoi nous avons inventé PowerShell.
Vous constaterez que le traitement de texte ne vous donnera pas ce que vous voulez sous Windows. À ce stade, vous souhaiterez utiliser PowerShell. NOTE - ce n'est pas une affaire tout ou rien. Dans PowerShell, vous pouvez appeler vos outils Unix (et utiliser leur traitement 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’ya 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 les commentaires. Faites-nous savoir où nous en sommes au travail ou s'il vous manque un outil, nous le mettrons sur la liste et y arriverons. En toute honnêteté, nous sommes en train de nous sortir d'un trou de 30 ans, alors cela va prendre un certain temps. Cela dit, si vous prenez la version bêta de Windows Server 2008 /R2 et/ou les versions bêta de nos produits serveur, vous serez surpris de la rapidité avec laquelle ce trou est corrigé.
En ce qui concerne l'utilisation - nous avons eu> 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 ne nécessite pas de téléchargement. V2 sera livré dans toutes les versions de Windows. Il sera activé par défaut pour toutes les éditions sauf Serveur de base où il s'agit d'un composant facultatif. Peu de temps après la livraison de Windows 7/Windows Server 2008 R2, nous ferons en sorte que V2 soit disponible sur toutes les plates-formes XP et versions ultérieures. 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 heureux. Une grande partie de la conception est fortement influencée par nos origines Unix. Par conséquent, bien que nous soyons assez différents, vous le comprendrez très rapidement (une fois que vous aurez trop insisté pour dire que ce n'est pas Unix :-)). Nous savons que les gens ont un budget d'apprentissage très limité - c'est pourquoi nous sommes extrêmement durs en matière de cohérence. Vous allez apprendre quelque chose et vous l'utiliserez encore et encore, encore et encore.
Expérience! Prendre plaisir! Engager!
grep
_Select-String_ et les opérateurs de commande _-match_ travaillent avec des expressions rationnelles. Vous pouvez également utiliser directement le support regex de .NET pour des fonctionnalités plus avancées.
trier
_Sort-Object_ est plus puissant (que je me souviens de sort de nix _). Autoriser le tri à plusieurs niveaux sur des expressions arbitraires. Ici, la maintenance du type sous-jacent par PowerShell aide; par exemple. une propriété DateTime sera triée comme une DateTime sans avoir à garantir le formatage dans un format pouvant être trié.
uniq
_Select-Object -Unique_
Perl (à quel point PowerShell se rapproche-t-il des capacités de Perl?)
En ce qui concerne l'étendue des bibliothèques de support spécifiques à un domaine de Perl: nulle part près (pour le moment).
Pour la programmation générale, PowerShell est certainement plus cohérent et plus facile à étendre. Le seul espace pour la modification de texte est équivalent à l'opérateur _.._ de Perl.
AWK
Cela fait assez longtemps que je n'ai pas utilisé AWK (ça doit être> 18 ans, car plus tard, je viens d'utiliser Perl), je ne peux donc 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 tellement ce qu'elle peut faire avec les objets du système de fichiers (et elle obtient ici toutes les informations, dir renvoie FileInfo ou FolderInfo objets, le cas échéant): c'est tout modèle de fournisseur.
Vous pouvez traiter le registre, le magasin de certificats, SQL Server, le cache RSS d'Internet Explorer, etc. comme un espace objet navigable avec les mêmes applets de commande que le système de fichiers.
PowerShell est certainement la voie à suivre sous Windows. Microsoft en a fait une partie de leurs exigences pour les futurs produits non destinés à la maison. D'où un support riche dans Exchange, un support dans SQL Server. Cela ne fera que s'agrandir.
Les TFS PowerToys en sont un exemple récent. De nombreuses opérations client TFS sont effectuées sans qu'il soit nécessaire de démarrer tf.exe à chaque fois (ce qui nécessite une nouvelle connexion au serveur TFS, etc.), ce qui facilite considérablement le traitement ultérieur des données. En plus de permettre un large accès à l’ensemble de l’API client TFS avec un niveau de détail supérieur à celui exposé dans 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 à Windows/COM/.NET; et l’utilisation d’objets au lieu de fichiers fournit un modèle de codage "plus riche"). Pour cette raison, j'utilisais et faisait la promotion de PowerShell depuis environ deux ans, avec la conviction que je suivais la "Parole de Bill".
Cependant, en tant que pragmatique, je ne suis plus sûr que PowerShell est une excellente réponse. Bien que c’est un excellent outil Windows et qu’il constitue une étape indispensable pour combler le trou historique de la ligne de commande Window, nous observons tous la prise en main de Microsoft par le grand public, mais il semble de plus en plus probable que Microsoft ait encore beaucoup à faire pour conserver son système d’exploitation. important pour l'entreprise du futur.
En effet, étant donné que mon travail est de plus en plus effectué dans des environnements hétérogènes, il me semble beaucoup plus utile d’utiliser des scripts Bash pour le moment, car ils fonctionnent non seulement sous Linux, Solaris et Mac OS X, mais ils fonctionnent également avec aide de Cygwin, sous Windows.
Donc, si vous croyez que l'avenir de l'OS est banalisé plutôt que monopolisé, optez pour une stratégie d'outils de développement agile qui s'éloigne autant que possible des outils propriétaires. Cependant, si vous voyez votre avenir dominé par tout ce qui est Redmond, optez pour PowerShell.
J'ai utilisé un peu de PowerShell pour l'automatisation de script. Même s’il est très gentil que l’environnement semble avoir été pensé beaucoup plus que les shells Unix, en pratique, l’utilisation d’objets au lieu de flux de texte est beaucoup plus lourde, et bon nombre des installations Unix développées au cours des 30 dernières années. il manque encore des années.
Cygwin est toujours mon environnement de script préféré pour les hôtes Windows. Cela dépasse certainement les solutions de rechange pour ce qui est de faire avancer les choses.
Il y a beaucoup de bonnes réponses ici, et voici ce que je pense. PowerShell est prêt si vous êtes ... Exemples:
grep = " Select-String -Pattern "
sort = "Sort-Object"
uniq = " Get-Unique "
fichier = " Get-Item "
cat = " Get-Content "
Perl/AWK/Sed ne sont pas des commandes, mais des utilitaires difficiles à comparer, mais vous pouvez presque tout faire dans PowerShell.
Ce n'est que récemment que j'ai commencé à jouer à PowerShell avec sérieux. Bien que, ces sept dernières années, j'ai travaillé dans un environnement presque exclusivement basé sur Windows, je viens d'un passé Unix et je me trouve constamment à essayer de "Unix-fy" mon expérience d'interaction sous Windows. C'est frustrant, c'est le moins qu'on puisse dire.
Il est juste de comparer PowerShell à quelque chose comme Bash , tcsh , ou zsh puisque des 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 telle que Select-String a une fonction très similaire à grep et est fourni en tant que module principal dans PowerShell ... afin que les lignes soient un peu floues.
Je pense que l'élément clé est la culture et le fait que les outils respectifs incarnent leurs cultures respectives:
- Unix est une culture basée sur des fichiers , (en général non Unicode) et basée sur du texte . 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 démarré sous forme d'interface graphique et les fonctions administratives ont récemment commencé à cesser d'être exclusivement basées sur l'interface graphique. Nous pouvons nous attendre à ce que l'expérience d'Unix en ligne de commande soit plus riche et plus mature, compte tenu de son avance considérable sur PowerShell, et mon expérience est à la hauteur. Sur ce point, selon mon expérience:
L’expérience administrative d’Unix vise à rendre les choses faciles à faire en un minimum de touches; ceci est probablement dû à la situation historique de devoir administrer un serveur via une connexion lente à 9 600 bauds. PowerShell a maintenant des alias qui permettent de contourner la norme plutôt verbeuse Verb-Noun , mais connaître ces alias est un peu un peu douleur (quelqu'un sait quelque chose de mieux que:
alias | where {$_.ResolvedCommandName -eq "<command>"}?).Un exemple de la manière riche dont l’histoire peut être manipulée:
Les commandes
iptablessont souvent longues et les répéter avec de légères différences serait une douleur s'il n'y avait pas qu'une seule des nombreuses fonctionnalités intéressantes de la manipulation de l'historique intégrée dans Bash , donc insérer une règle iptables comme suit:iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPTune deuxième fois pour une autre caméra ("
camera-2"), n’est qu’un cas de délivrance:!!:s/-1-/-2-/:s/50/51ce qui signifie "effectuer la commande précédente, mais substituer
-1-avec-2-et50avec51.L’expérience Unix est optimisée pour les dactylographes tactiles; on peut presque tout faire sans quitter la position "à la maison". Par exemple, dans Bash , utilisez les raccourcis clavier Emacs (oui, Bash prend également en charge vi les liaisons), le parcours de l'historique est effectué à l'aide de Ctrl-P et Ctrl-N tout en se déplaçant au début et à la fin d'une ligne se fait en utilisant Ctrl-A et Ctrl-E respectivement ... et cela ne s'arrête définitivement pas là. Essayez même la navigation la plus simple dans la console PowerShell sans quitter votre position d'origine et vous êtes en difficulté.
- Des choses simples comme la pagination polyvalente (à la moins ) sous Unix ne semblent pas être disponibles immédiatement avec PowerShell, ce qui est un peu frustrant et il n’existe pas de riche expérience en tant qu’éditeur. Soit. Bien sûr, on peut toujours télécharger des outils tiers qui combleront ces lacunes, mais ce serait bien si ces choses-là étaient juste "là", comme si elles avaient à peu près toutes les saveurs d'Unix.
La culture Windows, du moins en termes d’API système, est largement régie par les frameworks de support, à savoir, COM et . NET , tous deux hautement structurés et basés sur des objets. D'autre part, l'accès aux API Unix se faisait 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 de système d’exploitation respectifs. PowerShell est par nature structuré (tout est un objet) et Bash - and-friends basé sur des fichiers. L'API structurée à la disposition d'un programmeur PowerShell est vaste (correspondant essentiellement à l'immensité de l'ensemble existant d'interfaces standard COM et .NET).
En bref, bien que les capacités de script de PowerShell soient sans doute plus puissantes que Bash (surtout si l’on prend en compte la disponibilité du .NET BCL ), l'expérience interactive est nettement plus faible, en particulier si vous abordez la question sous un angle entièrement basé sur la console et sur la console (autant de têtes Unix sont).
Je ne suis certes pas un utilisateur très expérimenté de PowerShell, mais le peu que j’ai exposé m’a beaucoup impressionné. Vous pouvez chaîner les cmdlets intégrées pour faire à peu près tout ce que vous pourriez faire à l'aide d'une invite Unix. Il y a également un avantage supplémentaire à effectuer des opérations telles que l'exportation au format CSV, des tableaux HTML et des types plus détaillés de systèmes sys-admin. emplois. Et si vous avez vraiment besoin de quelque chose comme Sed, il y a toujours nixUtils ou GnuWin32 , que vous pouvez intégrer assez facilement à Powershell.
En tant qu'utilisateur Unix de longue date, j'avais toutefois un peu de mal à m'habituer au schéma de nommage des commandes, et j'en aurais certainement profité davantage si j'avais connu davantage de .NET.
Donc, en gros, je dis que ça vaut la peine de l’apprendre si le fait qu’il ne s’agit que de Windows ne pose pas de problème.
Si vous aimez les scripts Shell, vous allez adorer PowerShell!
Commencez par visite guidée de Microsoft Command Shell (Ars Technica).
Lorsque vous comparez PowerShell à la combinaison Cygwin/Perl/Shell, sachez que PowerShell ne représente que la partie "Shell" de cette combinaison.
Vous pouvez toutefois appeler n'importe quelle commande de PowerShell comme vous le faites depuis cmd.exe ou Cygwin. Il ( ne ré-implémente pas les fonctions spécifiées , et ce n'est certainement pas comparable à Perl.
C'est "juste" un Shell, mais cela facilite la programmation en fournissant une interface confortable à l'univers .Net.
Notez également que PowerShell requiert WinXP, Srv2003 ou une version ultérieure, ce qui peut poser problème en fonction de votre infrastructure informatique.
Mise à jour:
Je ne savais pas quel genre de débat philosophique ma réponse allait déclencher.
J'ai posté ma réponse dans le contexte de la question: Comparez PowerShell à Cygwin, 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). L'appel des méthodes .Net diffère uniquement par l'ajout d'un espace de nom ou d'un objet à l'appel.
Sa programmabilité découle du framework .Net et non de quoi que ce soit spécifique au "langage" de PowerShell.
Je dirais que je pense 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;)
Jusque-là, profitez du comparaisons .
Alors que mes expériences récentes me conduisaient au plus profond des appels PowerShell et .NET, je dois dire que PowerShell can remplace Cygwin et Unix Shell.
Je ne suis pas sûr de Perl, mais comme PowerShell et Perl sont tous deux des langages de programmation complets, je lui donne un oui pour remplacer Perl également.
Une des choses que PowerShell a au-dessus de Cygwin et de Bash ordinaire sous * nix, est sa capacité à effectuer des appels DLL en mode bac à sable, en manipulant le système d’exploitation via des appels d’API directs, des méthodes WMI et même des objets COM. Que diriez-vous de lancer Internet Explorer via du code, puis de faire ce que vous voulez avec le 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 de les exporter au format CSV, en utilisant des messages électroniques, du texte et en fait tout type de format de fichier existant ou non existant? (Avec des compétences appropriées pour créer un fichier valide à partir des données reçues, bien sûr, mais les fichiers CSV sont facilement disponibles).
De plus, une sécurité supplémentaire est disponible via des cmdlets et des scripts signés, des stratégies de groupe et des stratégies d'exécution signées qui aident à empêcher le code malveillant de s'exécuter sur votre système, même si vous les exécutez en tant qu'administrateur.
À propos des commandes mises en œuvre - la réponse de Richard les répertorie ainsi que la capacité de PowerShell d’émuler leurs fonctionnalités.
Déterminer si PowerShell est suffisant pour justifier le basculement - ceci est davantage une question de préférence personnelle, même si de plus en plus de services Windows fournissent des applets de commande PowerShell pour les contrôler, ne pas utiliser PowerShell avec ces services est considéré comme un obstacle. (Le serveur Hyper-V est le principal service de ce type. Il offre également la possibilité d’en faire plus avec les applets de commande PowerShell qu'avec l’interface graphique!)
Cette réponse a probablement cinq ans de retard, mais si quelqu'un exécute des tâches administratives ou des scripts généraux sur Windows, il doit absolument essayer d'utiliser PowerShell à ses propres fins.
TL; DR - Je ne déteste pas Windows ou PowerShell. Je ne peux tout simplement pas faire dans Windows ou sur PowerShell.
Personnellement, je trouve toujours que PowerShell est au mieux décevant.
- la complétion par tabulation des chemins de répertoire ne sont pas composés, obligeant l'utilisateur à entrer un séparateur de chemin après chaque complétion de nom.
- Je pense toujours que Windows ne connaît même pas le concept de chemin ou de ce qu’il est, sans indicateur d’accès utilisateur à la maison accessible
~/en deçà de@environment://somejibberish/%user_home% NTFS est toujours un désordre et apparemment le sera toujours, bonne chance pour naviguer.
interface cmd-esque, Le dinosaure cmd.exe est toujours visible dans PowerShell,
edit->markétant toujours le seul moyen de copier des informations, et en ne copiant que sous la forme de blocs rectangulaires d'espace terminal visible. etedit->pasteétant toujours le seul moyen de coller des chaînes dans le terminal.Le peindre en bleu ne le rend pas plus attrayant. Cela ne me dérange pas que les développeurs MS aient un goût pour la couleur.
Windows s'ouvre toujours dans le coin supérieur gauche de l'écran. Pour ceux qui utilisent des barres de tâches verticales, cela est incroyablement ennuyeux, d'autant plus que la barre de tâches de Windows couvre le seul coin de la fenêtre donnant accès à la fonctionnalité copier/coller.
Je ne peux pas parler beaucoup sur le terrain de la fenêtre d'outils comprend. Étant donné qu’il existe tout un ensemble d’outils CLI sous licence libre et à code source libre, livrés avec PowerShell avec, à ma connaissance, aucun d’eux n’est une déception absolue.
- PowerShell
wgetutilise des arguments apparemment incomparables pour GNU wget, grâce à une petite lueur d'espoir, qui ne sert à rien. - PowerShell POSIX n’est pas compatible avec Bash, en particulier l’opérateur
&&n’est pas géré, ce qui rend la plus simple des commandes conditionnelles qui suit.
Je ne connais pas l'homme; Je lui ai donné un coup, je l'ai vraiment fait; J'essaie encore de tenter le coup dans l'espoir que ce sera moins inutile la prochaine fois que je l'ouvrirai. Je ne peux rien faire dans PowerShell, et je peux difficilement faire des choses avec un vrai projet pour apporter des outils GNU à Windows.
MySysGit me donne l'invite du dinosaure, cmd.exe, avec quelques GNU outils, et elle reste très décevante, mais elle fonctionne enfin à la fin. Et la commande Git s'exécutera dans Git Bash.
Mintty for MySysGit donne l’interface Cygwin sur l’environnement de mysysgit, permettant de copier et coller un objet (select to copy (mouse)), shift+ins coller, quelle modernité ...). Cependant, des choses comme git Push sont cassées dans Mintty.
Je ne veux pas me déchaîner, mais je vois toujours d’énormes problèmes d’utilisation de la ligne de commande sous Windows, même avec des outils tels que Cygwin.
PS: Le fait que quelque chose puisse être fait dans PowerShell ne le rend pas utilisable . La facilité d'utilisation 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.
Les applets de commande de PowerShell sont très jolies et fonctionnent de manière fiable. Leur approche orientée objet me séduit beaucoup car je suis un développeur Java/C #, mais ce n'est pas du tout un ensemble complet. Comme il est orienté objet, il manque beaucoup de flux de texte de la maturité du jeu d'outils POSIX (awk et sed pour en nommer quelques-uns).
La meilleure réponse que j'ai trouvée au dilemme d'aimer OO techniques et d'aimer la maturité des outils POSIX est d'utiliser les deux! L'un des principaux avantages de PowerShell est qu'il permet de canaliser parfaitement les objets vers des flux standard. PowerShell utilise par défaut 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 transmettre la sortie à un processus standard dépourvu de pipeline d'objets, il convertit d'abord les objets en un flux de texte. PowerShell est un excellent endroit pour héberger les outils POSIX!
Le meilleur ensemble d'outils POSIX est GnuWin32 . Cela prend plus de 5 secondes à installer, mais cela en vaut la peine et, autant que je sache, cela ne modifie pas votre système (registres, c:\windows\* dossiers, etc.), à l'exception de la copie de fichiers dans les répertoires vous spécifiez. C’est très pratique, 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 le exe (il provient du site SourceForge ) en le dirigeant vers un répertoire approprié (je vais utiliser C:\bin). Il créera un répertoire GetGnuWin32 dans lequel vous exécuterez download.bat, puis install.bat (sans paramètres), après quoi il y aura un répertoire C:\bin\GetGnuWin32\gnuwin32\bin qui est le plus dossier utile qui a déjà existé sur une machine Windows. Ajoutez ce répertoire à votre chemin et vous êtes prêt.
Pourquoi ne pas utiliser les deux? Appelez les scripts PowerShell dans Cygwin comme tout autre script interprété tel que Perl, etc.
Je le fais assez que j'ai écrit https://bitbucket.org/jbianchi/powershell pour un wrapper Bash à appeler powershell.exe dans Cygwin. Il peut être utilisé comme Shebang comme première ligne d'un script .ps1 de powershell.exe (étant donné que PowerShell utilise également "#" comme commentaire). Voir https://bitbucket.org/jbianchi/powershell/wiki/Home pour des exemples.
Je n'ai pas vu que le PowerShell a vraiment décollé, du moins pas encore. Donc, il ne vaut peut-être pas la peine de l’apprendre si les autres membres de votre équipe ne le savent pas déjà.
Par contre, il serait peut-être préférable que vous utilisiez un langage de script que d'autres puissent utiliser, Perl comme vous l'avez mentionné ou d'autres comme Ruby ou Python.
Je pense que tout dépend de ce que vous devez faire. Personnellement, j’utilise Python pour mes scripts personnels, mais je sais que lorsque je commence à écrire quelque chose que je ne pourrai jamais le transmettre - j’essaie donc de ne rien faire de trop révolutionnaire.
Dans quelques lignes, Cygwin et PowerShell sont des outils différents. Toutefois, si Cygwin est installé sur votre ordinateur, vous pouvez exécuter les exécutables Cygwin dans une session PowerShell. Je suis tellement habitué à PowerShell que je n'utilise plus maintenant grep, sort, awk, etc. Il existe de nombreuses alternatives intégrées dans PowerShell, et sinon, vous pouvez trouver une applet de commande.
L’outil principal que j’utilise est ssh.exe, mais au sein d’une session PowerShell.
Cela fonctionne très bien.
PowerShell est très puissant, plus puissant que les standards intégrés aux shells Unix (mais uniquement parce qu'il inclut une grande partie des fonctionnalités habituellement proposées aux sous-programmes). En outre, considérez que vous pouvez écrire des applets dans n’importe quel langage .NET, y compris IronPython, IronRuby, PerlNet, etc. ou peu importe...
J'ai trouvé que la programmation PowerShell ne valait pas la peine.
J'ai plusieurs années d'expérience avec les scripts Shell sous Unix, mais j'ai trouvé extrêmement difficile de faire grand-chose avec PowerShell.
Il semble que de nombreuses fonctions nécessitent d'interroger l'interface de gestion Windows et d'émettre 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, cela serait simple .. .
find . -name \*.xyz -exec rm {} \;
Après quelques heures de lecture avec Scripting.FileSystemObject et WScript.Shell et en émettant "SELECT * FROM Win32_ShortcutFile WHERE Drive =" "& drive &" "AND Path =" "& searchFolder &" "", j’ai finalement abandonné et réglé pour la commande Recherche de l'Explorateur Windows et il suffit de le faire manuellement. Il y a probablement un moyen de faire ce que je voulais, mais je ne voyais rien 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 trouvé ce qui me manquait: le -recurse L'option 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