Question Soucis avec le cmdlet Trace-command

Salut,
j'ai 2 petits soucis avec la cmdlet Trace-Command.
Le premier, la valeur Errors pour le paramètre -Option ne renvoie rien, alors que j'essaie de tracer uniquement les erreurs :
[code:1]
Del Trace.log
Trace-command -Name * -Option Errors -Exp {[DateTime] $Date=\"31/12/2000\"} -FilePath Trace.log
[/code:1]
A noter que cela fonctionne avec
[code:1]-Option Method,Errors [/code:1]

Le second, dépendant du premier, j'aimerais si possible concatèner les 2 dernières instructions du code suivant :
[code:1]
Del Trace.log
Trace-command -Name * -Option Method,Errors -Exp {[DateTime] $Date=\"31/12/2000\"} -FilePath Trace.log
Select-string -Path trace.log -Pattern \": Exception\"|% {$_.Line}[/code:1]
Afin d'éviter le fichier temporaire Trace.log

Si vous avez qq infos là-dessus...
Merci

Curieux. Pour le problème d'Errors, je vais creuser...

Pour ce qui est d'éviter le fichier temporaire, ça me paraît difficile! Tu peux toujours utiliser -psHost au lieu de -FilePath pour rediriger les résultats vers la console, mais je n'ai pas l'impression qu'on puisse filtrer les résultats au fil de l'eau en envoyant la sortie de trace-command vers un select-string. De toute évidence, avec -psHost la sortie est forcée vers la console et non pas vers \"stdout\".

Il y a peut-être moyen de bricoler pour récupérer ces informations de débuggage autrement, mais à mon avis le fichier temporaire reste une solution plus simple et plus performante dans la majorité des cas.

Janel

Salut,
janel écrit:

De toute évidence, avec -psHost la sortie est forcée vers la console et non pas vers \"stdout\".

Oui c'est bien ce que j'ai compris, ce qui manque à mon avis dans la conception de PS c'est l'usage de flux en mémoire au lieu de fichier physique, à moins d'utiliser un ramdisk mais ce n'est pas natif sous windows.
Ce n'est pas vraiment un pb puisque j'ai une solution , je voulais juste améliorer les choses.
janel écrit:

le fichier temporaire reste une solution plus simple et plus performante dans la majorité des cas.

C'est vrai, le mieux est parfois l'ennemi du bien.

Reste le soucis avec le paramètre -option, j'ai recherché sur le site connect mais sans succès.
Vu l'architecture du produit et la finesse qu'il peut parfois avoir je ne suis pas persuadé que cela soit un bug, cqfd.
Merci pour ta réponse.

A priori les commandelettes de traçage ont été conçues pour les développeurs de PowerShell et laissées à dispo des utilisateurs sans véritable objectif de fournir un service opérationnel.

Donc, sur l'air de \"dis-moi ce dont tu as besoin, je te dirai comment t'en passer\", peux-tu décrire un peu plus le problème que tu essaies de résoudre avec trace-command? Il est probable qu'il y ait d'autres moyens d'y arriver.

Janel

janel écrit:

peux-tu décrire un peu plus le problème que tu essaies de résoudre avec trace-command?

Comme je le disais dans ma 1er réponse c'était plus une tentative d'amélioration.
Je n'ai pas de pb, je suis en train de rédiger un tutoriel sur les variables contraintes :
[code:1]
$SMA=\"System.Management.Automation\"
#...
[DateTime] $Date1=\"01/01/1900\"
[DateTime] $Date2=\"12/31/1999\"
[DateTime] $Date=\"10/09/1950\"

$ContraintedEtendu=New-object \"$SMA.ValidateRangeAttribute\" $Date1, $Date2
(Get-Variable Date).Attributes.add($ContraintedEtendu)
[DateTime] $Date=\"01/01/2000\"
[/code:1]
On obtient tjrs ce msg d'erreur générique :

Validation impossible en raison d'une valeur non valide (01/01/2000 00:00:00) pour la variable Date.

Je voulais juste indiquer comment retrouver la véritable cause de l'erreur, puisque l'on peut créer ces propres classes de contrainte :
[code:1]
Trace-command -Name Metadata -Option All -Exp {[DateTime] $Date=\"01/01/2000\"} -FilePath Trace.log
Select-string -Path trace.log -Pattern \": Exception\"|% {$_.Line}
[/code:1]
Ce qui donne ceci :

Metadata Information: 0 : Exception System.Management.Automation.ValidationMetadataException: L'argument (01/01/2000 00:00:00) était supérieur à la plage maximale (31/12/1999 00:00:00).

Metadata Information: 0 : Exception System.Management.Automation.ValidationMetadataException: Validation impossible en raison d'une valeur non valide (01/01/2000 00:00:00) pour la variable Date.

Ainsi on récupére l’exception d’origine qui n’est malheureusement pas placée dans la propriété $Error[0].Exception.InnerException.
Je n'ai pas trouvé d'autre manière de visualiser ce comportement, en dehors de Reflector.
C'était aussi pour donner un exemple d'utilisation de ce cmdlet:
janel écrit:

A priori les commandelettes de traçage ont été conçues pour les développeurs de PowerShell et laissées à dispo des utilisateurs sans véritable objectif de fournir un service opérationnel.

C'est vrai qu'à première vue il paraît bien inutile pour des tâches d'administration
S'il autorisait la trace du déroulement d'un script cela aurait été trés utile.<br><br>Message édité par: BatchMan, à: 18/04/08 15:58