PowerShell est-il prêt à remplacer mon shell Cygwin sur Windows?

je me demande si je dois apprendre PowerShell, ou simplement rester avec Cygwin /scripts Perl/scripts 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 je serais vraiment en train d'écrire autant de scripts à usage général, ou si les gens pourraient même les utiliser.

les scripts Unix sont si puissants, PowerShell se rapproche assez pour justifier le changement?

voici quelques-unes des choses spécifiques (ou équivalents) que je rechercherais dans PowerShell:

  • grep
  • trier
  • uniq
  • Perl (comment fermer n'PowerShell venir en Perl capacités?)
  • AWK
  • sed
  • du fichier de commande qui donne des informations sur les fichiers)
  • etc.
370
demandé sur Peter Mortensen 2009-02-21 22:42:06

18 réponses

les outils ne sont que des outils.

Ils aident ou pas.

Tu as besoin d'aide ou pas.

si vous connaissez Unix et ces outils font ce que vous avez besoin d'eux pour faire sur Windows - alors vous êtes un gars heureux et il n'y a pas besoin d'apprendre PowerShell (sauf si vous voulez explorer).

Mon intention première était d'inclure un ensemble d'outils Unix dans Windows et être fait avec elle (un certain nombre d'entre nous dans l'équipe de profondes Unix une bonne dose de respect pour cette communauté. Ce que j'ai découvert, 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 cert, etc, etc. En d'autres termes, UNIX est un écosystème entier auto-réglé autour des fichiers texte. Les outils de traitement de texte sont donc des outils de gestion efficaces. Windows est un écosystème complètement différent auto-accordé autour des API et des objets. C'est pour ça qu'on a inventé PowerShell.

ce que je pense que vous trouverez est qu'il y aura beaucoup d'occasions où le traitement de texte ne vous obtiendrez pas ce que vous voulez sur Windows. À ce moment-là, vous voudrez ramasser PowerShell. REMARQUE - il n'est pas un tout ou rien. Au sein de PowerShell, vous pouvez appeler vos outils Unix (et utiliser leur processus de texte ou le traitement de texte de PowerShell). Vous pouvez aussi appeler PowerShell à partir de vos outils Unix et obtenir du texte.

encore une fois - il n'y a pas de religion ici-notre l'accent est sur vous donnant les outils dont vous avez besoin pour réussir. C'est pourquoi nous sommes des passionnés de la rétroaction. Faites - nous savoir où nous tombons au travail ou où vous n'avez pas d'outil dont vous avez besoin et nous le mettrons sur la liste et nous y arriverons. En toute honnêteté, nous sommes en train de nous sortir d'un trou de 30 ans, donc ça va prendre un moment. Cela dit, si vous prenez la beta de Windows Server 2008 /R2 et/ou les bêtas de nos produits de serveur, je pense que vous serez choqué à la façon dont rapidement que le trou est exécuté.

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 parce qu'il est inclus comme un composant optionnel et n'a pas besoin d'un téléchargement. V2 embarquera dans toutes les versions de Windows. Il sera disponible par défaut pour toutes les éditions sauf Server core où il s'agit d'un composant optionnel. Peu de temps après Windows 7/Windows Server 2008 R2 navires, nous allons rendre V2 disponible sur toutes les plateformes XP et supé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 assez heureux. Une grande partie du design est fortement influencée par nos arrière-plans Unix, donc même si nous sommes assez différents, vous le remarquerez très rapidement (après avoir juré que ce n'est pas Unix: -)). Nous savons que les gens ont un budget très limité pour apprendre - c'est pourquoi nous sommes super dur sur la cohérence. Vous allez apprendre quelque chose et puis vous l'utiliserez encore et encore et encore.

l'Expérience! Profitez-en! S'engager!

753
répondu Jeffrey Snover - MSFT 2015-05-30 16:18:14

grep

Select-String applet de commande et de -match opérateur de travailler avec les regexes. 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 *nix sort ). Permet le tri à plusieurs niveaux sur des expressions arbitraires. Ici le maintien de PSH du type sous-jacent aide; par exemple, une propriété DateTime sera triée en tant que DateTime sans avoir à assurer le formatage dans un format sortable.

uniq

Select-Object -Unique

Perl (comment fermer n'PowerShell venir à Perl capacités?)

en termes de l'étendue de Perl des bibliothèques de soutien spécifiques au domaine: nulle part proche (encore).

pour la programmation générale, PSH est certainement plus cohésif et cohérent, et plus facile à étendre. La seule lacune pour le munging de texte est quelque chose d'équivalent à l'opérateur .. de perl.

awk

il a été assez longtemps depuis l'utilisation de awk (doit être >18 ans, depuis plus tard, je viens d'utiliser perl), donc ne peut pas vraiment commenter.

sed

[Voir ci-dessus]

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

la force de PSH ici n'est pas tellement ce qu'il peut faire avec les objets du système de fichiers (et il obtient toutes les informations ici, dir retourne FileInfo ou FolderInfo objets selon le cas) est que c'est le modèle de fournisseur entier.

vous pouvez traiter le registre, le magasin de certificats, le serveur SQL, le cache RSS D'IE etc. comme un espace d'objet navigable par les mêmes cmdlets que le système de fichiers.

PSH est certainement la voie à suivre sur Windows. Les États membres en ont fait une partie de leurs besoins pour de futurs produits non domestiques. Par conséquent, un support riche en échange, un support en SQL Server, cela ne va que s'étendre.

un exemple récent est le TFS PowerToys. De nombreuses opérations client de TFS sont effectuées sans avoir à démarrer tf.exe à chaque fois (ce qui nécessite un nouveau serveur TFS) connexion etc.) et est nettement plus facile à traiter ensuite les données. En plus de permettre un accès étendu à L'ensemble de L'API client de TFS à un plus grand détail que celui exposé dans L'un ou l'autre des Team Explorer de TF.EXE.

116
répondu Richard 2012-10-24 03:03:40

en tant que quelqu'un dont la carrière s'est concentrée sur le développement D'entreprise de Windows de 1997 - 2010, la réponse évidente serait Powershell pour toutes les bonnes raisons indiquées ci-dessus (par exemple, il fait partie de la stratégie d'entreprise de MS; il s'intègre bien avec Windows/COM/.NET; et en utilisant des objets au lieu de fichiers fournit un modèle de codage "plus riche"). C'est pour cette raison que J'ai utilisé et promu Powershell pendant les deux dernières années environ, avec la conviction expresse que je suivais la "Parole de Bill."

cependant, en tant que pragmatique, Je ne suis plus sûr que Powershell soit une si bonne réponse. Alors que C'est un excellent outil Windows et fournit une étape très nécessaire pour combler le trou historique qui est la ligne de commande de fenêtre, comme nous regardons tous l'emprise de MS sur le consommateur informatique glisser, il semble de plus en plus probable que MS a une bataille massive à l'avenir pour garder son OS aussi important pour l'entreprise de l'avenir.

en effet, étant donné que je trouve mon travail est de plus en plus hétérogène environnements, je trouve qu'il est beaucoup plus utile d'utiliser des scripts bash pour le moment, car ils ne fonctionnent pas seulement sur Linux, Solaris et Mac OS X, mais aussi-avec L'aide de Cygwin-sur Windows.

donc si vous croyez à la croyance que l'avenir de L'OS est marchandisé plutôt qu'un monopolisé, alors il semble logique d'opter pour une stratégie d'outil de développement agile qui se tient loin des outils propriétaires lorsque possible. Si toutefois vous voyez votre futur être dominé par Redmond va chercher Powershell.

56
répondu Ubiguchi 2011-01-07 17:12:23

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 des coquilles Unix, dans la pratique l'utilisation d'objets au lieu de flux de texte est beaucoup plus grotesque, et beaucoup D'installations Unix qui ont été développées au cours des 30 dernières années sont toujours manquantes.

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

32
répondu Daishiman 2014-12-11 22:07:14

Beaucoup de grandes de grandes réponses, voici mon point de vue. PS est prêt si vous l'êtes... Exemple

grep = " Select-String-Pattern "

tri = "Tri-Objet"

uniq = " Get-Unique

file = " Get-Item "

cat = " Get-Content

Perl/Awk / Sed ne sont pas command mais utilities donc difficile à comparer, mais vous pouvez faire presque tout en Powershell.

14
répondu Vic 2015-09-17 08:22:32

ce n'est que récemment que j'ai commencé à bavarder dans PS avec un certain degré de sérieux. Bien que depuis sept ans j'ai travaillé dans un environnement presque exclusivement basé sur Windows, je viens D'un arrière-plan Unix et je me retrouve constamment à essayer de "Unix-fy" mon expérience d'interaction sur Windows. C'est frustrant pour dire le moins.

il est juste de comparer PS à quelque chose comme Bash , tcsh ou zsh depuis des utilitaires comme grep , sed , awk , trouver etc. ne font pas, à proprement parler, partie du shell; ils feront toujours partie de n'importe quel environnement Unix. Cela dit, une commande PS comme Select-String a une fonction très similaire à grep et est livré avec un module de base en PS ... donc les lignes peuvent être un peu floues.

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

  • Unix est un basé sur un fichier , (en général, non Unicode) base de texte de la culture. Les fichiers de Configuration sont presque exclusivement texte "1519370920 de fichiers". Windows, d'un autre côté, 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) a toujours été la ligne de commande et le terminal virtuel. Windows a commencé comme un GUI et ce n'est que récemment que les fonctions administratives ont commencé à s'éloigner de exclusivement GUI-based. Nous pouvons nous attendre à ce que L'expérience Unix sur la ligne de commande soit plus riche, plus mature étant donné l'avance significative qu'elle a sur PS , et mon expérience correspond à cela. Sur ce, dans mon expérience:

    • L'expérience administrative D'Unix vise à rendre les choses faciles à faire dans un montant minimal de touches; ceci est probablement dû à la situation historique de devoir administrer un serveur sur une connexion lente 9600 baud. Maintenant PS n'ont d'alias qui vont un long chemin pour arriver autour du plutôt verbeux Verbe-Substantif standard, mais connaître les alias est un peu de douleur (quelqu'un connais quelque chose de mieux que: alias | where {$_.ResolvedCommandName -eq "<command>"} ?).

      un exemple de la manière riche dans laquelle l'histoire peut être manipulé:

      iptables les commandes sont souvent longues et les répéter avec de légères différences serait une douleur si ce n'était pour une des nombreuses caractéristiques soignées de manipulation de l'histoire intégré dans Bash , donc l'insertion d'une règle iptables comme la suivante:

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

      une deuxième fois pour une autre caméra (" camera-2 "), est juste un cas de l'émission:

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

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

    • L'expérience Unix est optimisée pour les dactylographes; on peut pratiquement tout faire sans quitter la position" maison". Par exemple, dans Bash , en utilisant les Emacs Fixations de clé (Oui, Bash supporte aussi vi fixations), le cyclage à travers l'histoire est fait en utilisant Ctrl-P et Ctrl-N tout en se déplaçant au début et à l'extrémité d'une ligne est fait en utilisant Ctrl-A et Ctrl-E respectivement ... et il n'a certainement pas là. Essayez même la navigation la plus simple dans la console PS sans vous déplacer de la position d'origine et vous êtes en difficulté.

    • les choses simples comme la pagination polyvalente (ala moins ) sur Unix ne semblent pas être disponibles out-of-the-box en PS 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 certainement bien si ces choses étaient simplement "là" comme elles le sont sur À peu près n'importe quelle saveur D'Unix.
  • le La culture Windows, du moins en termes D'API système est largement mue par les cadres de soutien, à savoir., COM et . D'un autre côté, L'accès aux API Unix s'est traditionnellement fait par l'intermédiaire d'une interface de fichiers ( /dev et /proc ) ou d'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. PS est, par nature, structuré (tout est un objet) et Bash et les amis de fichier. L'API structurée qui est à la disposition d'un programmeur PS est vaste (essentiellement correspondant à l'immensité de l'ensemble existant d'interfaces standard COM et .NET).

En bref, bien que les fonctionnalités de script de PS sont sans doute plus puissant que Bash (surtout si l'on considère la disponibilité du .NET BCL ), l'expérience interactive est nettement plus faible, surtout si l'on y vient d'une perspective entièrement basée sur le clavier et la console (comme le sont de nombreuses têtes Unix).

13
répondu Eric Smith 2013-12-28 13:21:58

Je ne suis pas du tout un utilisateur très expérimenté de PowerShell, mais le petit morceau auquel j'ai été exposé m'a beaucoup impressionné. Vous pouvez enchaîner les cmdlets intégrés ensemble pour faire à peu près tout ce que vous pourriez faire à une invite Unix, et il y a de la bonté supplémentaire pour faire des choses comme exporter vers CSV, des tables HTML, et pour des types de travail d'admin-systèmes plus en profondeur. Et si vous avez vraiment besoin de quelque chose comme sed, il y a toujours UnixUtils ou GnuWin32 , que vous pourriez intégrer avec Powershell assez facilement.

en tant qu'utilisateur de longue date D'Unix, j'ai cependant eu un peu de mal à m'habituer au schéma de nommage de la commande, et j'en aurais certainement profité davantage si j'en savais plus .NET.

donc essentiellement, je dis qu'il vaut la peine de l'apprendre si les fenêtres-seulement-ness de celui-ci ne pose pas de problème.

8
répondu yalestar 2009-02-21 20:05:17

si vous aimez shell scripting vous aimerez PowerShell!

Commencer à Une visite guidée de la Commande Microsoft Shell (Ars Technica).

7
répondu Nick 2014-12-11 22:08:05

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 invoquer N'importe quelle commande de PowerShell comme vous le faites de cmd.exe ou Cygwin. Il ne pas re-mettre en œuvre les fonctions spécifiées, et il est certainement pas comparable à Perl.

il est "juste" un shell, mais il rend la programmation plus facile fournissant un interface confortable avec L'univers.Net.

gardez également à l'esprit que PowerShell nécessite WinXP, Srv2003 ou plus, ce qui peut poser un problème en fonction de votre infrastructure informatique.

mise à jour:

Je n'avais aucune idée du genre de débat philosophique que ma réponse allait déclencher.

j'ai posté ma réponse dans le contexte de la question: comparez 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 commandes, les fonctions utilisateur et les commandes externes (.EXE. ,chauve. ,cmd). Seules les méthodes d'invocation .Net diffèrent par l'ajout d'un namespace ou d'un objet dans l'appel.

sa programmabilité provient de .net framework, 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 mis en œuvre comme PowerShell scripts en cours d'exécution sur un serveur web ;)

jusque - là, profitez des comparaisons .

6
répondu devio 2009-02-22 11:44:29

comme mes récentes expériences m'ont mené dans les profondeurs de Powershell et.NET calls, je dois dire que Powershell peut remplacer Cygwin et Unix shell. Je ne suis pas sûr de Perl, mais comme Powershell et Perl sont des langages de programmation complets, je dis oui au remplacement de Perl aussi. Une chose que Powershell a au-dessus de Cygwin et bash ordinaire sous *nix, est sa capacité à effectuer des appels DLL, en manipulant le système d'exploitation via API directe les appels, les méthodes WMI et même les objets COM. Que diriez-vous de lancer IE via le code, puis faire tout ce que vous voulez avec son document affiché, en émulant efficacement une extrémité arrière pour un serveur Web? Que diriez-vous de recueillir des données à partir de serveurs SQL et d'autres fournisseurs de données, de les analyser et d'exporter en tant que CSV, Messages mail, texte et en fait tout type de formats de fichiers existants et non-existants? (Avec les compétences appropriées de créer un fichier valide à partir des données reçues, bien sûr, mais CSV sont facilement disponibles) et il ya un supplément sécurité disponible via des cmdlets et des scripts signés, des politiques de groupe et des politiques d'exécution qui aident à empêcher les codes malveillants de fonctionner sur votre système même si vous les exécutez en tant qu'administrateur.

sur les commandes qui sont mises en œuvre - la réponse de Richard les énumère et la capacité de Powershell d'émuler déjà leur fonctionnalité.

si Powershell est forte pour justifier le changement - c'est plus une question de préférence personnelle, bien que de plus en plus de Services Windows fournissent des cmdlets 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 premier tel service, il fournit également la possibilité de faire plus avec les cmdlets Powershell qu'avec L'interface graphique!)

probablement cette réponse est de cinq ans de retard, mais encore, si quelqu'un effectue des tâches administratives ou des scripts généraux de diverses choses sur Windows, ils devraient certainement essayer exploiter Powershell à leurs fins.

6
répondu Vesper 2015-06-17 20:25:17

TL;DR -- je ne déteste pas les Fenêtres ou Powershell, je ne peux pas faire rien dans windows ou sur Powershell.

personnellement, je trouve toujours powershell décevant au mieux.

    "1519160920 onglet" achèvement des chemins de répertoire ne sont pas composé, obligeant l'utilisateur à entrer un séparateur de chemin après chaque nom d'achèvement.
  • concept de chemin ou de ce qu'est un chemin, sans indicateur d'accès à la maison de l'utilisateur ~/ manque de quelque @environment://somejibberish/%user_home%

  • NTFS est toujours un gâchis et apparemment le sera toujours, bonne chance à naviguer.

  • cmd-esque de l'interface, Le dinosaure cmd.exe est encore visible dans Powershell, edit->mark étant toujours le seul moyen de copier l'information, et la copie uniquement sous la forme de blocs rectangulaires de terminal visible espace. et edit->paste encore 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 développeurs MS ayant un goût dans la couleur cependant.

  • les fenêtres s'ouvrent toujours dans le coin supérieur gauche de l'écran, pour quelqu'un qui utilise des barres de tâches verticales. coin de la fenêtre qui donne accès à la fonctionnalité copier/coller.

je ne peux pas parler beaucoup sur le terrain des outils de windows. Étant donné qu'il y a tout un ensemble d'outils cli open-source, sous licence libre, et des vaisseaux powershell avec, à ma connaissance, aucun d'eux n'est une déception totale.

  • powershell wget prend des arguments apparemment incomparables à gnu wget, grâce à une lueur d'espoir de façon portable-inutile.
  • powershell posix n'est pas compatible bash, en particulier l'opérateur && n'est pas manipulé, ce qui rend la commande conditionnelle la plus simple à suivre pas une chose.

je ne sais pas l'homme, j'ai donné un coup de feu, je n'ai vraiment; j'essaie toujours de donner un coup de feu dans l'espoir que la prochaine fois que je l'ai ouverte, il sera moins inutile. Je ne peux rien faire dans powershell, et je peux faire des choses avec un vrai projet pour apporter des outils gnu pour Windows.

MySysGit me donne le cmd DE dinosaure.invite d'exe avec quelques outils gnu, encore très décevant, mais enfin l'achèvement du chemin fonctionne. et la commande git s'exécute en gitBash

Mintty pour MySysGit donne l'interface Cygwin sur l'environnement de mysysgit, faisant copier et coller une chose. (sélectionner pour copier (souris), Maj + ins coller, comment moderne...) cependant, des choses comme git push sont brisé dans Mintty.

Je ne veux pas me vanter, mais je vois encore d'énormes problèmes avec l'utilisabilité de la ligne de commande sur windows même avec des outils comme Cygwin.

P. S. Juste à cause de quelque chose de peut faire en powershell, ne débite pas le faire utilisable , la facilité d'utilisation est plus profond que de la capacité et c'est ce que j'ai tendance a se concentrer sur quand vous essayez d'utiliser un produit en tant que consommateur.

4
répondu ThorSummoner 2014-03-26 23:36:46

les cmdlets de powershell sont très agréables et fonctionnent de manière fiable. Leur orientation objet me plaît beaucoup puisque je suis un développeur java / C#, mais ce n'est pas du tout un ensemble complet. Depuis qu'il est orienté objet, il a manqué beaucoup de la flux de texte maturité de L'ensemble D'outils POSIX ( awk et sed pour n'en nommer que quelques-uns).

la meilleure réponse que j'ai trouvé au dilemme d'aimer les techniques D'OO et d'aimer la maturité dans le POSIX outils est d'utiliser les deux! Un grand aspect de Powershell est qu'il fait un excellent travail piping objets to standard streams. Powershell utilise par défaut un pipeline d'objets pour transporter ses objets. Ce ne sont pas les flux standard (standard, erreur standard et standard). Lorsque Powershell doit passer la sortie à un processus standard qui n'a pas de pipeline d'objet, il convertit d'abord les objets en flux de texte. Comme il le fait si bien, Powershell fait un excellent endroit pour host POSIX tools!

le meilleur jeu D'outils POSIX est GnuWin32 . Il faut plus de 5 secondes pour l'installer, mais cela en vaut la peine, et pour autant que je sache, il ne modifie pas votre système (registre, dossiers c:\windows\* , etc.) sauf copier des fichiers dans les répertoires que vous spécifiez. C'est très agréable car si vous mettez les outils dans un répertoire partagé, beaucoup de gens peuvent y accéder simultanément.

Installation De GnuWin32 Instructions

télécharger et exécuter le exe (il est à partir du site SourceForge ) pointant vers un répertoire approprié (je vais utiliser c:\bin ). Il va créer 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 répertoire le plus utile qui ait jamais existé sur une machine Windows. Ajouter ce répertoire sur ton chemin et tu es prêt à y aller.

3
répondu Limited Atonement 2012-10-26 14:52:45

Je n'ai pas vu que la Powershell a vraiment décollé, du moins pas encore. Il se peut donc que cela ne vaille pas la peine de l'apprendre à moins que les autres membres de votre équipe ne le sachent déjà.

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

je pense que beaucoup de cela dépend de ce que vous devez faire. Personnellement, J'ai utilisé Python pour mon propre scripts personnels, mais je sais quand je commence à écrire quelque chose que je ne serai jamais en mesure de transmettre - donc j'essaie de ne pas faire quelque chose de trop révolutionnaire.

2
répondu greg 2009-02-21 20:12:20

Pourquoi ne pas utiliser les deux? Appelez les scripts PowerShell dans Cygwin comme tous les autres scripts interprétés comme perl,etc.

j'en fais assez pour écrire https://bitbucket.org/jbianchi/powershell pour un emballage de bash pour appeler powershell.exe à Cygwin. Peut être utilisé comme un Shebang comme la première ligne d'une powershell.exe .script ps1 (puisque powershell utilise aussi "#" comme commentaire). Voir https://bitbucket.org/jbianchi/powershell/wiki/Home pour exemples

2
répondu johnnyB 2013-10-25 17:01:16

PowerShell est très puissant, plus puissant que le standard intégré des coques Unix (mais seulement parce qu'il inclut une grande partie de la fonctionnalité habituellement écaillée aux sous-programmes). Aussi, considérez que vous pouvez écrire des applets dans n'importe quelle langue.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 la même manière que bash, korn, ou n'importe quoi d'autre...

1
répondu Erik Funkenbusch 2009-02-22 03:22:23

dans un couple de lignes, Cygwin et Powershell sont des outils différents mais si vous avez Cygwin installé, vous pouvez exécuter les exécutables Cygwin dans une session Powershell. J'ai tellement pris l'habitude de Powershell que maintenant je n'utilise plus grep, sort, awk, etc. Il y a des alternatives à peu près intégrées dans Powershell, et si ce n'est pas le cas, vous pouvez trouver un cmdlet là-bas.

le principal outil que j'utilise est ssh.exe mais dans une session de Powershell.

Fonctionne très bien.

1
répondu yaxzone 2013-09-10 09:31:25

vous pouvez également essayer d'exécuter des scripts Bash sur windows en utilisant BashWin à https://github.com/skanga/BashWin

-1
répondu skanga 2012-07-13 17:06:47

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 beaucoup de choses avec PowerShell.

il semble que de nombreuses fonctions exigent que vous interrogiez L'Interface de gestion de 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 supprime tous les fichiers avec un suffixe spécifique d'une arborescence de répertoires. sous Unix, ce serait un simple ... 

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

après quelques heures à tourner autour avec Scripting.FileSystemObject et WScript.Shell et l'émission" SELECT * de Win32_ShortcutFile où Drive = ' & drive & "' et Path = ' & searchFolder&"', j'ai finalement abandonné et réglé pour Windows Explorer recherche commande et juste le faire manuellement. Il y a probablement une façon 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 ne valaient rien.

EDIT Heh, bien sûr dès que j'ai écrit ceci j'ai fouillé autour de plus et j'ai trouvé ce que j'avais manqué: l'option -recurse à la commande Supprimer-élément est faulty (révélé si vous utilisez get-help remove-item -detailed ).

j'ai essayé "remove-item -filtre"* .xyz' -recurse" et il n'était pas de travail, donc j'ai laissé tomber.

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

-1
répondu TMN 2013-04-11 21:46:34