janvier
2010
Voici un autre billet initialement publié sur notre blog interne, et que je republie en externe.
Pour montrer comment j’utilise PowerShell (le shell remplaçant DOS, et développé par Microsoft sur .NET), voici un petit exemple de lancement de programme en boucle. C’est le script que j’utilise en ce moment pour essayer de reproduire un gel d’un de nos logiciels qui est constaté chez un client.
[Contexte : ce gel arrive 2 à 3 fois par an, et uniquement chez ce client – la fréquence d’apparition est donc très faible, c’est pourquoi je suis conduit à faire des centaines de milliers d’exécution pour essayer de le reproduire – et c’est pourquoi l’automatisation via PowerShell est très utile]
Ce script maintient en exécution simultanée x instances d’un programme donné, jusqu’à ce qu’on parvienne à un nombre donné de lancements.
Ce premier fragment de code ci-dessous montre plusieurs aspects intéressants de PowerShell :
- on peut écrire des fonctions
- on dispose d’environnements de développement modernes, comme PowerGUI par exemple
- on a un accès direct au framework .NET, comme le montre l’appel [diagnostics.process]::start : comme il n’y a pas de commande équivalent dans le shell, on fait faire le travail par .NET directement
- on manipule des objets (voir les appels de méthodes comme .Count)
- les opérateurs booléens ne sont pas très naturels : -eq, -lt, -ge etc. C’est mon seul reproche à ce langage !
Note : quand je fais ces essais directement sur mon PC, j’ai constaté qu’il était très utile de baisser un peu la priorité des processus, afin de garder un certain contrôle sur le PC. Voici comment faire :
Voici maintenant le reste du script qui utilise les fonctions ci-dessus, une simple boucle :
Le langage fournit donc tout ce que que l’on peut espérer d’un langage de programmation moderne. Il est sans doute possible de faire tout cela en DOS, mais explorer DOS m’a toujours paru au dessus de mes forces ! Dans le passé j’ai toujours préférer travailler avec cygwin pour profiter des possibilités de scripts à la Unix – ce n’est plus justifié aujourd’hui avec PowerShell, une bonne solution native sous Windows !
Note 27 janvier 2010 : merci à Laurent Dardenne de m’avoir signalé les liens erronés vers les images.
3 Commentaires + Ajouter un commentaire
Commentaires récents
- Des tableaux pour l’intégration d’un équipier dans une équipe Scrum dans
- Rétrospectives, la directive première dans
- Des tableaux pour l’intégration d’un équipier dans une équipe Scrum dans
- Des tableaux pour l’intégration d’un équipier dans une équipe Scrum dans
- Des tableaux pour l’intégration d’un équipier dans une équipe Scrum dans
>>Laurent, effectivement depuis quelques jours je découvre avec plaisir la version 2
Mon prochain tutoriel aborde une de ses nouvelles fonctionnalités, les fonctions avancées.
Il y a pas mal de choses à voir dans la V2, mais je trouve la documentation insuffisante.
>>Tout à fait d’accord avec les limitations, je me suis un peu emballé !
C’est en m’emballant que j’ai trouvé les qq limites citées
A l’origine PowerShell n’est pas fait pour coder comme en C# ou autres langages dit évolués, en même temps les concepteurs de PS sont à l’écoute des propositions d’évolutions émisent par les utilisateurs et tiennent comptes des retours d’expériences.
De mon coté je pense que l’équipe de MS à un modèle de conception très évoluée et qu’il le livre par étapes, ces limitations seront peut être lévées un de ces jours…
Laurent, effectivement depuis quelques jours je découvre avec plaisir la version 2, notamment Start/Stop-Process, Start-Job, Get-Job…
Tout à fait d’accord avec les limitations, je me suis un peu emballé !
Merci pour les autres précisions.
Bruno
Salut,
je me permets qq remarques :
concernant la gestion des process désormais la version 2 de PowerShell propose le cmdlet Start-Process. Ce qui fait qu’il vaut mieux préciser la version de PowerShell que tu utilises/références.
C’est vrai que les opérateurs ne sont pas intuitifs, mais cela dépend des langages de scripting que l’on connait, par exemple en batch ce sont les mêmes.
Certains sont similaires à ceux de Perl qui, d’après Bruce Payette l’un des concepteurs du langage, a pas mal influencé PowerShell.
À propos de ceci :
« Le langage fournit donc tout ce que l’on peut espérer d’un langage de programmation moderne. »
Si tu références la version 1, ce n’est pas, à mon avis, tout à fait le cas il lui manque qq fonctionnalités : création de classe (héritage), surcharge de méthodes/fonctions, la gestion des génériques est mal aisée, pas de délégués, pas de gestion d’événement, pas de thread( cf. Runspace), …
C’est un langage de scripting puissant gérant des objets, mais il lui manque certaines fonctionnalités. La version 2 améliore les choses (try/catch, eventing, remoting, job en tâches de fond), je pense que les prochaines versions apporteront d’autres améliorations au langage.
Dans le document « WMF_RC_Release_Notes_English », fourni avec la version 2, il y est indiqué que les mots clés suivants sont réservés pour un prochain usage : USING, CLASS, DEFINE, et VAR.
Son point fort est tout même le dynamisme, mais ce n’est pas de la POO.
Avec ce shell, on peut automatiser de très nombreuses tâches, bien qu’à un moment donné, ça coince
Enfin concernant le code :
– Dans la fonction get-process l’usage de measure-object n’est pas nécessaire, ceci me semble suffisant :
@(get-process $name).Count
Avec le groupe @() on s’assure de tjr renvoyer un tableau ( 0 ou 1 process), du coup on accède à sa propriété count.
– Pour les valeurs des énumérations, PriorityClass, tu peux utiliser directement une chaîne de caractères, ton approche documente le code, mais en même temps on ne peut affecter à cette variable uniquement une valeur de l’énumération ProcessPriorityClass.
– Enfin pour le Write-Host on peut aussi utiliser directement la substitution de variable :
Write-Host « nb lauched $already_Launched/$Total_t_Lauch »