Discussion :

[Dr. Phallus]

Spock amis terriens, aujourd'hui m'est venu l'idée saugrenue de faire un ambitieux comparatif entre ces trois langages de script en vue d'une administration de moults systèmes et réseaux MS Windows...

Merci de bien vouloir m'éclairer de vos lumineuses connaissances en m'indiquant quels sont les points forts et inconvénients de chaque langage (ou de m'indiquer un langage plus approprié à mes besoins)

[vpourchet]

pseudo atypique

bonne chance pour ta comparaison en tout cas

Powershell est pas mal, les autres je ne les connais pas

[Dr. Phallus]

Je te remercie, mon brave

PS : Ceci n'est pas un "free post"

[Laurent Dardenne]

Salut,

ou de m'indiquer un langage plus approprié à mes besoins

Ne les connaissant pas, difficile de te répondre sur ce point.

PowerShell vs AutoIT vs Kixtart
Je ne connais vraiment que le premier il ne permet pas nativement(mais cela reste possible):
l'automatisation de GUI, la compilation de script, l'usage simple d'API Win32 comme AutoIt,
KiXtart me semble fortement lié au logon scripts, là où l'usage de PowerShell s'avérera moins aisé.

Pour PowerShell, les possibilités du framework dotnet permettent de dépasser les limites du scripting, difficile de créer des DSL(Domain Specific Language) avec AutoIT vs Kixtart , même si cela n'est plus du domaine de l'administration système.
[ame="http://www.slideshare.net/glaforge/domainspecific-languages-avec-groovy"]Domain-Specific Languages avec Groovy@@AMEPARAM@@ssplayer2.swf?doc=t1-usi-2008-1216131127435526-9&stripped_title=domainspecific-languages-avec-groovy@@AMEPARAM@@t1-usi-2008-1216131127435526-9@@AMEPARAM@@domainspecific-languages-avec-groovy[/ame]
On peut créer des accés à des sources de données spécialisées à l'aide de provider, PowerShell est donc aussi un framework technique (développement).

De mon coté il m'est difficile de comparer un Shell basé objet avec des langages de scripts spécialisés. Voir ce comparatif de différents Shell.
AutoIT et Kixtart sont certainement plus facile et plus rapide à apprendre et à maîtriser.

De coupler ces différents langages n'est pas une hérésie, reste que cela nécessite de connaitre les trois (plus les batchs et VBS).

Si on consulte les offres d'emplois liés aux métiers de l'administration de systèmes Microsoft, Powershell me semble devenir un pré-requis, étant donné que les dernières versions de ses produits proposent une administration via ce Shell (cmdlets dédiés).

[john.fender]

Bonjour,

Si tu raisonnes en mode natif (qu'es-ce que je dois apporter sur mon système pour que cela marche), tu obtiens 2 frameworks :

.Net pour le powershell (donc un déploiement volumineux qui impactera les performances des machines cibles).
. Executables Kixtart.
. AutoIt génère je crois ses propres .exe

Si tu veux quelqueschose qui passera en mode natif sur un large panel d'OS, tu as tout WSH : cmd.exe (batch) et cscript.exe (vbs). L'intérêt du mode natif est qu'on t'emmerderas pas avec si tu déploies sur serveur ou si l'entreprise rechigne à augmenter l'angle de vulnérabilité de ses postes (plus j'ai d'application, plus elles sont potentiellement dangereuses pour le poste).

En terme d'usage, PowerShell est plutôt à destination des serveurs (logique), AutoIt plutôt comme un langage d'automation pour les applications incapables (que cela soit voulu ou non) de s'installer silencieusement. Kixtart, c'est une extension du batch à mon sens.

Personnement, powershell fait bien sur un CV, Batch et VBS sont outdated et unvaluable sur un CV mais rendent bien des services. Kixart et AutoIT je m'en sert pour l'exotique uniquement.

J'aime bien le batch dans le sens ou c'est un langage simple, mal foutu mais rapide ce qui convient bien aux scripts et au besoin. On peux l'étendre facilement via ajout d'utilitaire unix GNU ou autre( il y en a beaucoup). Pour aller plus loin, on peux toujours utiliser VBS ou PERL (qui est une synthèse du C, de plusieurs utilitaire UNIX comme sed ou awk, du shell unix lui même et très axé expression régulière qui sont si souvent utilisé en shell).

Voili voilou.