Question Listing DACL

janel écrit:

Tout ça est fort juste mais horriblement complexe pour un besoin à la base relativement simple (en tout cas à formuler).

Que le sujet soit complexe oui mais il ne l'est pas horriblement, sinon NT peut être perçu comme complexe tout en formulant le besoin d'origine simplement : j'ai besoin d'un OS avec un système de droits.
La MOA à un besoin simple. Oui la programmation système peut être complexe mais qui est a commencé
janel écrit:

Et contrairement à ce qu'affirme Laurent,

Je ne fais que donner mon point de vue, mais effectivement pour
Laurent Dardenne écrit:

C'est ici qu'on comprend que PowerShell est un Framework technique avant d'être un shell.

J'aurais du dire \"je\", et le terme \"avant\" laisse supposer que l'objectif premier ait été de concevoir un framework avant le shell, alors que l'objectif est la réalisation du shell au travers d'un framework.
Pour moi s'il n'existe pas de framework, i.e. d'API, les outils comme PowerGUI n'existerait pas. PowerShell est donc \"ouvert\" (à toutes propositions, bien évidemment )
Ensuite on peut dire, comme il est aujourd'hui perçu par les développeurs, que Powershell est un outil uniquement dédié aux admins.
D'accord.Rien de nouveau sous le soleil, chacun reste dans son coin.
Laurent Dardenne écrit:

je dirais que PowerShell est avant tout un shell.

Je n'ai pas dit qu'il n'en était pas un. J'y vois d'abord un framework avant d'y voir un Shell, c'est ma perception de ce qui constitue cet outil. Mais je manipule la pluspart du temps un Shell, c'est vrai.
Je voulais effectivement, dans mon explication, découpler les termes Power et Shell mais cela n'avait aucun sens de les dissocier. En tous cas l'exercice me semblait vain, voir périlleux.
Laurent Dardenne écrit:

Tu n'as pas absolument besoin d'avoir toutes les fonctionnalités disponibles dans le Framework .NET, à partir du moment où un exécutable peut les offrir

\"à partir du moment\" ,je suis tout à fait d'accord moins on code mieux on se porte, mais quelque fois \"le moment\" tarde à venir, d'où la recherche d'une solution.
Laurent Dardenne écrit:

Donc, si tu connais un outil en ligne de commande qui peut modifier les privilèges d'un jeton utilisateur, tu as déjà résolu 90% du problème.

Ici aussi je suis d'accord et je suppose que c'est aussi le cas pour Mephisto, mais jusqu'ici on ne le connait pas cet outil.
Et dans ce cas cet outil n'est-il pas complexe ?
Laurent Dardenne écrit:

Là, PowerShell se révèle généralement plus souple et plus performant que le bon vieux shell CMD.EXE.

Re-re d'accord, mais si on doit passer par des outils externes, comme sous CMD, quel est l'apport de PowerShell ?
Le Power associé au Shell serait donc du domaine du marketing ? Je ne pense pas, mais c'est en formulant de tels besoins que la communauté peut faire avancer les choses, à minima énoncer les limites de l'outil.
Oui l'informatique c'est complexe mais elle n'est pour moi que le reflet de la complexité de la société actuelle.
Un paysan du 18eme n'avait pas besoin de placer dans ces champs des droits d'accès sur ses épis de blé...<br><br>Message édité par: Laurent Dardenne, à: 3/03/09 14:58

Je ne crois pas qu'on puisse dire que le shell est limité parce qu'il ne propose pas de commandelette standard pour manipuler les privilèges NT. Bien sûr, ce serait super d'avoir ça. Mais se plaint-on du fait que CMD.EXE n'intègre pas robocopy.exe, perl.exe, ou tous les autres outils en ligne de commande que les développeurs crèent depuis des décennies?

PowerShell bénéficie de cet héritage. Tous les outils accessibles à partir de CMD.EXE le sont à partir de PowerShell. Même les commandes natives de CMD.EXE puisque CMD.EXE lui-même est invocable depuis PowerShell (et inversement, d'ailleurs).

En plus, PowerShell apporte sa pierre à l'édifice en changeant de paradigme. Les éléments manipulés par le shell ne sont plus du texte mais des véritables objets système. C'est là que le Framework est utile. Mais il n'est pas la seule brique de PowerShell puisque les objets WMI sont également accessibles, et les objets COM, etc.

Cela dit, l'importance du Framework dans la conception de PowerShell est essentielle, mais il faut bien faire la part des choses entre les deux composants - pour moi, le Framework est une interface de présentation du système, alors que PowerShell est une interface d'accès au système.

Je disais que PowerShell est plus souple et plus performant que CMD.EXE pour l'intégration des outils en ligne de commande, justement parce que PowerShell ne se contente pas de prendre du texte et de le découper comme du texte. On peut donc appliquer des logiques à un plus haut niveau d'abstraction dans l'échanges des informations, même si les outils eux-mêmes sont des outils pré-PowerShell qui ne comprennent que du texte (en réception comme en émission).

Mais pour en revenir au problème de Mephisto, je suis persuadé qu'il existe des outils faisant ce qu'il cherche. En fait, je me rappelle avoir utilisé un outil de ce type il y a des années pour un besoin tout à fait similaire. Donc ça existe (et de toute façon ça n'a pas l'air bien compliqué à coder, c'est juste la transcription en code \&quot;managé\&quot; et donc directement accessible par des méthodes .NET dans PowerShell qui a l'air un peu compliquée).

Là je finis tout juste ma journée de boulot, un peu trop fatigué pour faire une recherche approfondie maintenant, mais je regarderai ça dans le week-end.

Janel