De ce point de vue-là, PowerShell n'est pas du tout un concurrent de Bash, de Zsh, de Tcsh ou autre, mais plutôt de Python ou de Perl. Ou peut-être quelque chose d'un nouveau genre.
Je dirais effectivement un nouveau genre, c'est la reunion d'un veritable langage de programmation avec un shell et un framework.
Powershell n'est pas non plus le dernier truc qui fait le café.
Par exemple, la réunion d'un langage de programmation et d'un shell existe déjà pour Perl avec psh http://www.focusresearch.com/gregor/sw/psh/
psh is a Perl program which executes a read-eval loop with enough options so that general behavior reasonably similar to more traditional shells like 'sh' or 'bash' can be achieved, while still allowing arbitrary perl expressions to be evaluated.
Il me semble qu'il y a un équivalent sous python, mais une recherche rapide n'a rien donné.
Le principe n'est pas nouveau, Rexx (ARexx pour moi car j'étais amigaïste) est encore plus vieux sur ce principe, permettant même aux programmes GUI d'exposer leur fonctionalité en créant une API port Rexx, ce qui les transformait en utilitaire "shell" pour automatiser les traitements en externalisant les scripts (contrairement à la tendance actuelle d'intégrer l'édition de script dans les programmes eux-même)
Le problème de tous ces hybrides, c'est qu'il faut apprendre le langage (et surtout la librairie qui va avec), alors que les commandes unix permettent de faire une chose et une seule facilement.
Le seul interêt d'un shell est de rentrer les directives de manière interactive orientées manipulation fichier (pas de commande "open file", "close file" à ajouter dans le code)
Un shell unix avec ses outils de base, tu peux déjà faire pas mal d'opération par rapport à un cmd.exe. Que je me connecte à un linux (défaut bash), un serveur AIX (défaut ksh), HP ou SUN, BSD, Darwin, j'ai toujours le même écosytéme de commandes (il y a des pièges parfois sur des différences d'option) qui permettent de couvrir beaucoup de cas courant de manipulation simple, et certains outils comme netcat sont vraiment géniaux (par exemple pour lire un film sur un ordinateur distant sans créer de partage réseau ou copier le fichier du film au préalable).
Et si j'en crois le site de microsoft http://www.microsoft.com/windowsserver2003/technologies/mana(...) , powershell est installé par défaut uniquement à partir de la version server 2008 (même si on pouvait la télécharger et l'installer à partir de XP).
Mieux vaut tard que jamais, mais on ne peut pas espérer se connecter sur une machine windows hors server 2008 et être sûr d'avoir un powershell à sa disposition.
Dans quelques années, la question ne se posera peut être plus, mais pour l'instant, ce n'est qu'une option.
Ce qui n'enléve rien aux possibilités de powershell et que c'est un bon de géant en avant pour les administrateurs windows par rapport à cmd.exe
Le but recherché entre shell et powershell n'est pas le même.
[^] # Re: Windows est rancunier
Posté par darkleon . En réponse à la dépêche Une année sans (MS) Windows : achever la conversion d'un utilisateur de Windows. Évalué à 2.
Je dirais effectivement un nouveau genre, c'est la reunion d'un veritable langage de programmation avec un shell et un framework.
Powershell n'est pas non plus le dernier truc qui fait le café.
Par exemple, la réunion d'un langage de programmation et d'un shell existe déjà pour Perl avec psh http://www.focusresearch.com/gregor/sw/psh/
psh is a Perl program which executes a read-eval loop with enough options so that general behavior reasonably similar to more traditional shells like 'sh' or 'bash' can be achieved, while still allowing arbitrary perl expressions to be evaluated.
Il me semble qu'il y a un équivalent sous python, mais une recherche rapide n'a rien donné.
Le principe n'est pas nouveau, Rexx (ARexx pour moi car j'étais amigaïste) est encore plus vieux sur ce principe, permettant même aux programmes GUI d'exposer leur fonctionalité en créant une API port Rexx, ce qui les transformait en utilitaire "shell" pour automatiser les traitements en externalisant les scripts (contrairement à la tendance actuelle d'intégrer l'édition de script dans les programmes eux-même)
Le problème de tous ces hybrides, c'est qu'il faut apprendre le langage (et surtout la librairie qui va avec), alors que les commandes unix permettent de faire une chose et une seule facilement.
Le seul interêt d'un shell est de rentrer les directives de manière interactive orientées manipulation fichier (pas de commande "open file", "close file" à ajouter dans le code)
Un shell unix avec ses outils de base, tu peux déjà faire pas mal d'opération par rapport à un cmd.exe. Que je me connecte à un linux (défaut bash), un serveur AIX (défaut ksh), HP ou SUN, BSD, Darwin, j'ai toujours le même écosytéme de commandes (il y a des pièges parfois sur des différences d'option) qui permettent de couvrir beaucoup de cas courant de manipulation simple, et certains outils comme netcat sont vraiment géniaux (par exemple pour lire un film sur un ordinateur distant sans créer de partage réseau ou copier le fichier du film au préalable).
Et si j'en crois le site de microsoft http://www.microsoft.com/windowsserver2003/technologies/mana(...) , powershell est installé par défaut uniquement à partir de la version server 2008 (même si on pouvait la télécharger et l'installer à partir de XP).
Mieux vaut tard que jamais, mais on ne peut pas espérer se connecter sur une machine windows hors server 2008 et être sûr d'avoir un powershell à sa disposition.
Dans quelques années, la question ne se posera peut être plus, mais pour l'instant, ce n'est qu'une option.
Ce qui n'enléve rien aux possibilités de powershell et que c'est un bon de géant en avant pour les administrateurs windows par rapport à cmd.exe
Le but recherché entre shell et powershell n'est pas le même.