10 bonnes raisons de passer à PowerShell et de ne plus faire de CommandLine application

Cela fait maintenant presque un an que j’ai eu l’occasion de me mettre à PowerShell. J’ai maintenant la conviction que tout bon développeur doit s’y mettre. Voici mes 10 meilleures raisons d’abandonner l’utilisation de la ligne de commande ou la création de commandline app au profit de scripts et de modules powershell.

Raison #10 : Devenir le meilleur ami des ops

Les ops utilisent déjà PowerShell depuis plusieurs années, car il remplit un vide énorme quand on le compare à la ligne de commande classique :

• Des branchements clairs,
• L’exécution à distance,
• Un vrai langage de programmation,
• De vraies variables.

Raison #9 : il est typé !

PowerShell est écrit en .Net et contrairement à la ligne de commande, on manipule des objets typés!

Raison #8 : Le paradigme “verbe-nom”

Il permet de rendre le langage très facilement découvrable : toutes les commandes ne sont pas bonnes à écrire. Il y a des règles. Cela permet de structurer le langage et évite des commandes “exotiques”. Il simplifie aussi la recherche via “get-command”

Raison #7 : Rétrocompabilitié

Il est compatible avec la ligne de commande : il est tout à fait possible d’appeler n’importe quel exécutable.

Raison #6 : programmation

Il se programme en .net: les Cmdlets s’écrivent en .Net, en héritant de Cmdlet :

[Cmdlet(VerbsCommon.Add, "Integer")]
public class AddIntegers : Cmdlet
{
[Parameter(Mandatory=true, Position=0)]
public int A { get; set; }

[Parameter(Mandatory = true, Position=1)]
public int B { get; set; }

protected override void ProcessRecord()
{
WriteObject(A + B);
}
}

Voici le résultat :

Raison #5: autocomplétion & aide

Powershell joue à  fond le jeu de la découverte : tout est disponible à l’autocomplétion, du nom des commandes aux paramètres ou même aux valeurs lorsqu’on a affaire à des énumérations par exemple. L’aide est nativement intégrée à PowerShell. Lors du développement, elle s’intègre dans des fichiers à part, ce qui simplifie leur écriture.

Raison #4: l’environnement de travail: PowerShell ISE

C’est un véritable IDE avec aide intégrée. C’est l’outil de travail de l’Ops.

Raison #3 : le pipelining

Il est possible d’appeller une même commande sur un jeu de données ou pour le transformer. C’est encore plus puissant que le pipe Unix, dans le cas de PowerShell ce sont des objets qui sont échangés.

Raison #2 : le formatage

Le formatage de PowerShell permet d’afficher les données en fonction du contexte sous forme de liste, de tableau, etc. Lors du développement ce formatage est décrit sous forme XML. Encore quelque chose de moins à coder.

Raison #1 : le packaging

Les modules Powershell engloblent du code, des scripts, du formatage. De plus à partir de powershell 3, ils peuvent être chargés automatiquement s’ils sont placés au bon endroit. Il n’est plus nécessaire de donner une doc d’installation à vos IT : juste un zip contenant le module qui va être décompressé au bon endroit.

Il y a plein d’autres bonnes raisons, j’espère que vous allez les trouver vous-même.

@+