Discussion :

[smyley]

Tu peux très bien être développeur amateur et concevoir par exemple un cmdlet pour gérer tes fichiers MP3 ou tes fichiers jpeg et autoriser la manipulation des tags.

Tu te vois faire un cmdlet pour ça ?!
Moi je me vois faire "Fichier>Nouveau>Application WinForms" et le coder tranquillement. Heureusement que pour lire une playlist on a pas besoin d'ouvrir un shell ...

En y repensant le domaine d'application de ton soft de setup peut peut-être se prêter au développement d'un provider PowerShell. Les administrateurs systèmes recherchent et manipulent souvent les informations sur les logiciels installés. Et là les professionnels te diront merci "l'amateur"

Tient, ça pourrai être une idée en effet (pour les admin XD mais une idée)
A cause de toi je vais devoir quand même me mettre à PowerShell

[tomlev]

A cause de toi je vais devoir quand même me mettre à PowerShell

Bien joué Laurent, tu as réussi à convaincre un réfractaire... faut dire, si tu le prends par les sentiments

[Laurent Dardenne]

Tu te vois faire un cmdlet pour ça ?!

Pas vraiment car je n'en ai pas une véritable utilité mais c'est celui qui a le besoin qui détermine la pertinence du choix. C'est une possibilité.
Un Cmdlet n'est qu'un template, un canevas, que l'on rempli. Je suis tenté de dire qu'ils ont, les concepteurs, automatisé la réalisation d'outil d'automatisation

Moi je me vois faire "Fichier>Nouveau>Application WinForms" et le coder tranquillement.

On est dans l'automatisation de tâches. On peut automatiser un GUI mais dans cas autant simplifier l'approche...

A cause de toi je vais devoir quand même me mettre à PowerShell

J'évite le triangle infernal

faut dire, si tu le prends par les sentiments

J'ai juste essayé de prendre un exemple qui lui parle.

Pour le moment au vue des résultats de ce sondage il y a deux opinions qui se détachent
- l'une est la méconnaissance du produit, difficile donc d'avoir un avis.
- l'autre une perception de redondance qui est raisonnée.

[smyley]

Bien joué Laurent, tu as réussi à convaincre un réfractaire... faut dire, si tu le prends par les sentiments

Non mais en fait, j'ai l'impression qu'on retombe toujours sur le cas "PowerShell c'est pour les admins" car bien que l'idée de Laurent me poussera surement à m'y mettre, ce sera pour simplifier la tâches des administrateurs. En tant que simple programmeur je ne suis toujours pas convaincu de sa "super utilité" ...

Un Cmdlet n'est qu'un template, un canevas, que l'on rempli. Je suis tenté de dire qu'ils ont, les concepteurs, automatisé la réalisation d'outil d'automatisation

Chose qui est adorée par les admins vu qu'ils ont un nombre important de tâches répétitives à faire. Pour le commun des mortel le nombre de tâche répétitives est beaucoup moins important ...

Pour le moment au vue des résultats de ce sondage il y a deux opinions qui se détachent
- l'une est la méconnaissance du produit, difficile donc d'avoir un avis.
- l'autre une perception de redondance qui est raisonnée.

Je suis pas seul

[Grand_grunt]

Même si ce n'est pas vraiment le sujet, je me permets d'indiquer au inconditionnels de l'interface graphique (histoire de troller un peu) que le stage qui m'a amené sur "Dev'.com" a pour objet d'écrire en C un outil (de traduction en quelque sorte, on va pas entrer dans les détails), certes tout simple, mais entièrement en ligne de commandes. Quelque chose comme "C:\programme.exe fichier.txt dictionnaire.txt", et qui écrira dans le dossier courant un "fichier.hex" traduit. Et cet humble machin sera utilisé par des gens dont l'informatique n'est pas le métier principal. Les logiciels en ligne de commande sont encore monnaie courante dans les domaines de l'électronique, de la programmation de micro-contrôleurs, de l'automatisme.. parce qu'ils sont simples, tournent sur de vieux PC, ne posent que rarement des soucis de compatibilité, et répondent finalement aux besoins simples et précis de certains utilisateurs.

La ligne de commande n'est pas morte. Sous Linux elle est toujours d'actualité. Et sous WIndows, PowerShell semble destiné à redonner une seconde vie à un MS-DOS émulé dans un "cmd.com" et dont on annonçait la disparition. Et bien non, et tant mieux!
Ce n'est pas parce que l'informatique avance et que l'on a maintenant sur tous les OS des interfaces en 3D, que les dinosaures n'ont pas leur mot à dire. Quand la ligne de commande est la meilleure réponse à un problème, pourquoi ne pas l'utiliser?
Et mieux vaut alors qu'elle soit la plus puissante et la plus riche possible !

[Laurent Dardenne]

Et sous WIndows, PowerShell semble destiné à redonner une seconde vie à un MS-DOS émulé dans un "cmd.com" et dont on annonçait la disparition.

PowerShell n'est pas un MS-DOS émulé. C'est une application console en ligne de commande mais la ressemblance s'arrête là.
PowerShell c'est aussi un moteur que l'on peut intégrer dans les applications GUI, la console proposée n'est qu'une implémentation du hosting.

[Marc Magnin]

Tout d'abord bonjour à tous.

Je fréquente régulièrement developpez.net mais je ne m'étais encore jamais inscrit sur le forum, une étape vient d’être franchie

Pour répondre au topic : Oui, j’utilise powershell en tant que développeur en collaboration avec l’administrateur système de ma société.

Suite au développement de logons scripts en WSH, j’ai redéveloppé un script en powershell afin d’en exploiter la puissance (traitements sur les fichiers XML, etc…).
Ce script, unique pour l’ensemble de la société, permet donc d’effectuer le mapping des ressources partagées sur les postes des utilisateurs lors de leur login, et ce en fonction de leur domaine, groupe et machine depuis l’active directory.
Une gestion convivial est effectuée par l’administrateur système depuis une interface graphique développée en C# synchronisée avec l’Active Directory.
Je pense développer une version libre d’exploitation de cet outil… il est très probable qu’il puisse rendre service à une part considérable de sociétés qui tendent à utiliser les technologies basées sur le PowerShell.

Si vous êtes intéressés par ce projet, n’hésitez pas à m’en faire part, cela permettra par exemple d’écourter le temps avant mise à disposition de cet outil.

[thbar]

Hello,

j'ai tendance à utiliser Rake (y compris sous Windows) pour tous mes scripts (administration, déploiement, outillage divers, analyse de logs).

En pratique je reste en Ruby/Rake, quitte à appeler PowerShell ou MsBuild pour des tâches atomiques précises pour lesquelles ils seraient plus adaptés. Ca me parait plus souple à l'usage!

Thibaut Barrère / LoGeek
--
http://blog.logeek.fr - learning content for developers
http://evolvingworker.com - tools for a better day

[anthyme]

Si on part plus dans l aspect "scripting" que "console" bin moi je fais plutot de l' IronPython.

Un super langage dynamique avec un acces total a la CLR et tout produit compilé en MSIL c'est vraiment génial pour automatiser autour de .net

[Laurent Dardenne]

Si vous êtes intéressés par ce projet, n’hésitez pas à m’en faire part, cela permettra par exemple d’écourter le temps avant mise à disposition de cet outil.

Je pense effectivement que cela peut intéresser de nombreuses personnes.

En pratique je reste en Ruby/Rake, quitte à appeler PowerShell ou MsBuild pour des tâches atomiques précises pour lesquelles ils seraient plus adaptés. Ca me parait plus souple à l'usage!

Si on part plus dans l aspect "scripting" que "console" bin moi je fais plutot de l' IronPython.

C'est sûr que pour l'automatisation de tâches chacun à ses préférences.

Concernant PowerShell et MsBuild, voir ce post:
http://blogs.msdn.com/powershell/arc...vironment.aspx

[apokrif]

En tant qu'utilisateur de Linux et adepte (accroc) de la ligne de commande, je n'aurais qu'un mot à dire, et sincère en plus: "Bravo Microsoft !" j'ai jeté un oeil à ce PowerShell, et j'avoue qu'un PowerShell m'aurait fait un peu plus hésité à l'époque où j'ai abandonné Windows..

Le problème c'est que PowerShell m'a l'air lourd, comparé aux shells Unix (ce qui comprend les shells Unix sous Windows...): je trouve qu'il manque un intermédiaire entre le cmd.exe et les outils de base trop restreints, et le PowerShell trop lourd et trop évolué. Peut-on se connecter par Telnet à une machine Windows, et lui parler avec command.com ou cmd.exe, comme on comunique en shell avec une machine Linux ?

Si vous êtes admin d'un serveur sous Windows, ou même sur votre PC de bureau, je vous invite fortement à essayer: c'est fou le temps que l'on gagne à ne plus déplacer la souris, dérouler des menus, faire des "OK" sur des boîtes de dialogue, etc..

Rappelons que la plupart des fonctions de l'interface graphique de Windows fonctionnent avec le clavier :-)

[Laurent Dardenne]

Salut,

Le problème c'est que PowerShell m'a l'air lourd, comparé aux shells Unix (ce qui comprend les shells Unix sous Windows...): je trouve qu'il manque un intermédiaire entre le cmd.exe et les outils de base trop restreints, et le PowerShell trop lourd et trop évolué.

Je suis curieux de connaître ton avis, peux-tu préciser ta pensée ?

Peut-on se connecter par Telnet à une machine Windows, et lui parler avec command.com ou cmd.exe, comme on comunique en shell avec une machine Linux ?

Voir la ctp 2 de PowerShell 2.0, basé sur WinRM (via SOAP). On peux imaginer un début de solution pour "piloter" un serveur Windows ou Linux. Bon là je suis dans le domaine du yaka mais cela semble réalisable.

Rappelons que la plupart des fonctions de l'interface graphique de Windows fonctionnent avec le clavier :-)

Certes, mais cela n'a rien à voir avec l'objectif de PowerShell à savoir l'automatisation (voir aussi).

[apokrif]

Voir la ctp 2 de PowerShell 2.0, basé sur WinRM (via SOAP). On peux imaginer un début de solution pour "piloter" un serveur Windows ou Linux. Bon là je suis dans le domaine du yaka mais cela semble réalisable.

Je cherchais l'équivalent - pas forcément avec PS ni même une version récente de Windows- de ce qu'on a sous Linux: on se connecte avec un logiciel standard et la console de l'utilisateur distant est reliée à l'interpréteur de commandes standard. Ce qui semble assez simple techniquement...

Certes, mais cela n'a rien à voir avec l'objectif de PowerShell à savoir l'automatisation

Je répondais à la remarque de Grand Grunt sur les interfaces graphiques. Si PS est destiné prioritairement à l'automatisation et secondairement au dialogue "de tous les jours" avec la machine (lancer une appli, copier des fichiers...) c'est qu'il manque peut-être toujours quelque chose à Windows: quelque chose de simple et efficace comme Bash, mais au moins dans la version que j'ai utilisée, bash sous Windows ressemble vraiment à une pièce rapportée: pas d'équivalent raccourci/symlink, écriture différente des chemins d'accès (il n'empêche que Bash me sert de shell sous W98, faute de mieux).

[Laurent Dardenne]

Je cherchais l'équivalent - pas forcément avec PS ni même une version récente de Windows- de ce qu'on a sous Linux

Ok, je comprend mieux.

c'est qu'il manque peut-être toujours quelque chose à Windows: quelque chose de simple et efficace comme Bash

Pour moi PowerShell l'est tout autant, ensuite comme je l'ai dit précédement, chacun à une préférence pour tel ou tel outil.

[Laurent Dardenne]

c'est qu'il manque peut-être toujours quelque chose à Windows: quelque chose de simple et efficace comme Bash,

C'était un des objectifs de l'équipe de développement il me semble à la lecture de ce post : http://blogs.msdn.com/powershell/arc...d-snippet.aspx

...
This range of activities, from interactive shell, to quick and dirty scripting, to formal production scripting is what we call the Admin Development Model. (Note that model of work is NOT limited to Admins - many people use this but it is critical for Admins.) PowerShell is very focused on supporting the Admin Development Model. That is why we have an interactive shell. That is why we struggled hard to find the right balance in our syntax and semantics between interactivity and scriptability. That is why we support a wide range of scripting styles from quick and dirty (bash-style) scripting to more advanced (Perl-style) scripting to more formal .NET programming. We wanted to ensure that you could learn a single tool and then decide how you were going to use that tool to solve the particular problem at hand.
...

[dev01]

Pour le plus gros problème de powershell reste sa lenteur ....
Je suis admin exchange 2007, du powershell j'en mange et attendre 3 mn que la console s'ouvre (d'accord elle a chargé les commandes exhcanges mais bon ) ça me gonfle profondément. Ensuite les temps de réaction de la complétion, ben c'est tout simplement une horreur.

Alors powershell oui, c'est bien c'est beau, mais alors c'est encore très très loin derrière les bash linux

[Laurent Dardenne]

Pour le plus gros problème de powershell reste sa lenteur ....

Pour ce point as-tu essayé de précompiler les assemblies ?
Voir
http://blogs.msdn.com/powershell/arc...e-gac-ps1.aspx
et
http://janel.spaces.live.com/Blog/cn...88C2!317.entry

Ensuite c'est inhérent à dotnet, et je sens comme une pointe de regret du code natif. Le code managé c'est un compromis

Pour la complétion si tu regardes le code de Powertab (par MOW) tu t'aperçois qu'il compile toutes les classes .NET/WMI pour améliorer la recherche.
PowerShell n'est certes pas la panacée mais existera-t-elle un jour ?

[dev01]

Pour ce point as-tu essayé de précompiler les assemblies ?
Voir
http://blogs.msdn.com/powershell/arc...e-gac-ps1.aspx
et
http://janel.spaces.live.com/Blog/cn...88C2!317.entry

Pour moi ça reste de la bidouille

Ensuite c'est inhérent à dotnet, et je sens comme une pointe de regret du code natif. Le code managé c'est un compromis

Oui et non. Déjà pourquoi la précompilation des assemblies powershell n'est pas faite à l'installation ? Ensuite un truc super qui s'appelle le threading et rien n'empeche de précharger un certain nombre de composant pendant que l'utilisateur réfléchi à ce qu'il veux faire.

Pour la complétion si tu regardes le code de Powertab (par MOW) tu t'aperçois qu'il compile toutes les classes .NET/WMI pour améliorer la recherche.

Et pourquoi le résultat n'est pas stocké ? Pourquoi pas un simple update ?

PowerShell n'est certes pas la panacée mais existera-t-elle un jour ?

Clairement aujourd'hui et pour moi, en terme de console d'admin, c'est bash et les outils linux/unix.

[Laurent Dardenne]

Déjà pourquoi la précompilation des assemblies powershell n'est pas faite à l'installation ?
...
Et pourquoi le résultat n'est pas stocké ? Pourquoi pas un simple update ?

Je veux bien faire l'avocat du diable mais je n'ai pas les réponses à ces questions. De ce que j'ai pu lire, l'équipe projet de PS a été contraint de sortir une version plus rapidement que prévu pour répondre aux besoins d'un autre produit, Exchange je crois.
En creusant on s'aperçoit qu'il y a effectivement quelques défauts, faut-il pour autant jeter le bébé avec l'eau du bain ?

[dev01]

Je veux bien faire l'avocat du diable mais je n'ai pas les réponses à ces questions. De ce que j'ai pu lire, l'équipe projet de PS a été contraint de sortir une version plus rapidement que prévu pour répondre aux besoins d'un autre produit, Exchange je crois.

For probable

En creusant on s'aperçoit qu'il y a effectivement quelques défauts, faut-il pour autant jeter le bébé avec l'eau du bain ?

Je ne jete pas PS, c'est un outil qui manquais sous windows. Je dit juste qu'il n'est pas fini et qu'il y a encore du boulot dessus. Un débat est fait pour amener des idées nouvelles et des retours d'expérience qu'ils soient bon ou mauvais . Ce n'est pas parce que je critique que je pense qu'il faut le jeter à la poubelle, loin de la