différence entre GetExpandedStringValue et expandenvironmentstrings

Dans le message:OBmZb0xTFHA.228@TK2MSFTNGP12.phx.gbl,

Bonjour Fred

Lorsque j'interroge dans bdr une variable d'environnement avec
GetExpandedStringValue, j'ai en retour une valeur inattendue :

Par exemple, j'interroge une valeur qui contient %UserProfile%

Au lieu de me renvoyer "C:Documents and Settings[session]"
(comme le fait wshshell.expandenvironmentstrings("%userprofile%"))

Il me renvoie "C:WINDOWSsystem32configsystemprofile"

Qu'est-ce que ça signifie ?
Quelle est la solution pour avoir un chemin "exploitable" ?

En regardant vos posts, je ne vois rien qui me laisse penser que
vous avez vu que c'est le chemin de l'utilisateur SYSTEM.
Excusez-moi si je me trompe.
Une piste de recherche peut-être ? Problème d'impersonation ?

Bien vu !

La question deviendrait donc : pourquoi wmi me sort la variable
d'environnement profil du système ?
Je cherche...

Je viens de tourner le problème dans tous les sens.
Il semble que l'on n'ait pas le choix.
Les appels avec le moniker winmgmts se font par délégation au
système. Donc il vaut mieux passer par le Shell pour ce cas précis.

Merci.
J'ai retourné un peu dans tous les sens les infos du msdn dans le post
précédent, et je n'ai pas trouvé non plus.

Dommage.

Merci de ton aide,

De rien,
J'avais aussi besoin d'approfondir ces points.
Heureusement qu'il y a le script center pour le WMI !
Je préfère tout de même pouvoir écrire les scripts sans trop faire de
copier/coller.

--
Fred

Bonjour Fred

J'avais aussi besoin d'approfondir ces points.
Heureusement qu'il y a le script center pour le WMI !
Je préfère tout de même pouvoir écrire les scripts sans trop faire de
copier/coller.

Puisqu'on discute...

Lorsque j'ai un pb avec un objet, j'essaie de m'en servir en VB, ce qui
donne la possibilité d'exécuter le programme pas à pas, de regarder le
contenu des variables en temps réel (et celles de l'objet créé), ça donne
aussi accès à intellisence et à l'explorateur d'objet (mais il faut déclarer
l'objet en early binding).


par exemple, pour essais avec WMI :

faut rajouter la référence
Microsoft WMI Scripting V 1.2 library

et déclarer l'objet ainsi :

Dim oReg As WbemScripting.SWbemObject
strOb =
"winmgmts:{impersonationLevel=impersonate,authenticationLevel=Connect}!\.rootdefault:StdRegProv"
Set oReg = GetObject(strOb)

Pour tout ceci, il est tout à fait possible d'utiliser Visual Basic 5 CCE,
qui est gratuit.

@+
pascal

Dans son message %23SXJnBAUFHA.2556@TK2MSFTNGP12.phx.gbl
Paskal nous dit :

Bonjour Fred

J'avais aussi besoin d'approfondir ces points.
Heureusement qu'il y a le script center pour le WMI !
Je préfère tout de même pouvoir écrire les scripts sans trop faire de
copier/coller.

Puisqu'on discute...

Lorsque j'ai un pb avec un objet, j'essaie de m'en servir en VB, ce
qui donne la possibilité d'exécuter le programme pas à pas, de
regarder le contenu des variables en temps réel (et celles de l'objet
créé), ça donne aussi accès à intellisence et à l'explorateur d'objet
(mais il faut déclarer l'objet en early binding).


par exemple, pour essais avec WMI :

faut rajouter la référence
Microsoft WMI Scripting V 1.2 library

et déclarer l'objet ainsi :

Dim oReg As WbemScripting.SWbemObject
strOb > "winmgmts:{impersonationLevel=impersonate,authenticationLevel=Connect}!\.rootdefault:StdRegProv"
Set oReg = GetObject(strOb)

Pour tout ceci, il est tout à fait possible d'utiliser Visual Basic 5
CCE, qui est gratuit.

@+
pascal

Bonsoir,
Oui, c'est ce que je fais aussi mais avec Word ou Excel.
Je n'ai pas eu l'occasion de faire du WMI en VBA mais j'ai eu l'occasion de
tester l'accès à WMI dans un petit développement sous Studio .NET il y a
peu.
En fait j'avais posté il y a quelque temps pour savoir si quelqu'un connait
une solution pour éditer des wsf.
J'utilise le script editor fourni avec Office mais c'est très limité. Il y a
quand même les numéros de ligne, très utiles pour retrouver les erreurs. On
peut aussi faire du pas à pas. Il manque la complétion automatique (pour les
objets déclarés en en-tête) et, curieusement, la possibilité de commenter
des blocs entiers de texte ?!?
Il faudrait que je fasse un essai de primal script. As-tu entendu parlé ?

--
Fred

Dans son message %23SXJnBAUFHA.2556@TK2MSFTNGP12.phx.gbl
Paskal nous dit :

Bonjour Fred

J'avais aussi besoin d'approfondir ces points.
Heureusement qu'il y a le script center pour le WMI !
Je préfère tout de même pouvoir écrire les scripts sans trop faire de
copier/coller.

Puisqu'on discute...

Lorsque j'ai un pb avec un objet, j'essaie de m'en servir en VB, ce
qui donne la possibilité d'exécuter le programme pas à pas, de
regarder le contenu des variables en temps réel (et celles de l'objet
créé), ça donne aussi accès à intellisence et à l'explorateur d'objet
(mais il faut déclarer l'objet en early binding).


par exemple, pour essais avec WMI :

faut rajouter la référence
Microsoft WMI Scripting V 1.2 library

et déclarer l'objet ainsi :

Dim oReg As WbemScripting.SWbemObject
strOb > "winmgmts:{impersonationLevel=impersonate,authenticationLevel=Connect}!\.rootdefault:StdRegProv"
Set oReg = GetObject(strOb)

Pour tout ceci, il est tout à fait possible d'utiliser Visual Basic 5
CCE, qui est gratuit.

@+
pascal

Re-bonsoir,
J'avais testé VS pour les wsf sans grand succès (je demeure cependant
persuadé qu'avec un "target-schema" adéquat cela peut se faire)
Je viens d'essayer d'éditer un vbs.

Set toto = CreateObject("Scripting.FileSystemObject")

Et bien cela suffit pour avoir la liste des propriétés/méthodes en
auto-complétion !
Je n'osais même pas l'espérer :-)
Il reste quelques petites choses à voir mais pour l'instant je n'ai pas
trouvé mieux.


--
Fred

Dans le message:%23SXJnBAUFHA.2556@TK2MSFTNGP12.phx.gbl,

Bonjour Fred

J'avais aussi besoin d'approfondir ces points.
Heureusement qu'il y a le script center pour le WMI !
Je préfère tout de même pouvoir écrire les scripts sans trop faire de
copier/coller.

Puisqu'on discute...

Lorsque j'ai un pb avec un objet, j'essaie de m'en servir en VB, ce
qui donne la possibilité d'exécuter le programme pas à pas, de
regarder le contenu des variables en temps réel (et celles de l'objet
créé), ça donne aussi accès à intellisence et à l'explorateur d'objet
(mais il faut déclarer l'objet en early binding).


par exemple, pour essais avec WMI :

faut rajouter la référence
Microsoft WMI Scripting V 1.2 library

et déclarer l'objet ainsi :

Dim oReg As WbemScripting.SWbemObject
strOb > "winmgmts:{impersonationLevel=impersonate,authenticationLevel=Connect}!\.rootdefault:StdRegProv"
Set oReg = GetObject(strOb)

Pour tout ceci, il est tout à fait possible d'utiliser Visual Basic 5
CCE, qui est gratuit.

@+
pascal

Bonjour,
Un dernier post à propos de VS .NET
J'ai trouvé comment éditer correctement un wsf avec toutes les
fonctionnalités intéressantes, y compris le late-binding avec
auto-complétion.

Voila :
Si je fais fichier nouveau Windows Script Host
J'obtiens ceci :

8<-------------------
<job id="main">
<script language="JScript">
WScript.Echo("JScript");
</script>

<script language="VBScript">
WScript.Echo "VBScript"
</script>
</job>
8<--------------------

Et l'éditeur me souligne job en m'indiquant : Le schéma actif ne prend pas
en charge l'élément 'job'
Pas très grave car tout fonctionne quand même (reconnaissance de syntaxe,
auto-complétion)

Il suffit en fait d'ajouter au début du fichier :
<package xmlns="http://schemas.microsoft.com/WindowsScriptHost">
et </package> en fin de fichier pour ne plus avoir les avertissements.

C'est dommage qu'on ne puisse exécuter à partir de l'environnement de
développement, mais on peut facilement ajouter un menu contextuel 'Déboguer'
sous Windows en jouant avec les associations de fichier.
Il manque l'auto-complétion pour les objets déclarés dans une balise
<object>.
Dommage aussi que les boutons de mise en commentaire restent obstinément
grisés dans la barre d'outil édition.


Un point fort : on peut ajouter dans l'explorateur d'objet toutes les
références habituelles (Scripting.Runtime, etc ..), on peut ainsi
copier/coller le nom des classes et les références restent d'un lancement à
l'autre de l'environnement.

PS : je suis en VS .NET 2003.

--
Fred

Bonjour Fred

Pour répondre à tes messages :

Il faudrait que je fasse un essai de primal script. As-tu entendu parlé ?
Non, absolument pas.... je vais faire un tour sur google.

J'avais testé VS pour les wsf...vbs
Set toto = CreateObject("Scripting.FileSystemObject")
Et bien cela suffit pour avoir la liste des propriétés/méthodes en
auto-complétion !
Je n'osais même pas l'espérer

Je suis également surpris ! C'est bon à savoir

Un dernier post à propos de VS .NET
J'ai trouvé comment éditer correctement un wsf...

Merci de l'info.

@+
pascal

J'avais aussi besoin d'approfondir ces points.
Heureusement qu'il y a le script center pour le WMI !
Je préfère tout de même pouvoir écrire les scripts sans trop faire
de copier/coller.

Puisqu'on discute...

Lorsque j'ai un pb avec un objet, j'essaie de m'en servir en VB, ce
qui donne la possibilité d'exécuter le programme pas à pas, de
regarder le contenu des variables en temps réel (et celles de l'objet
créé), ça donne aussi accès à intellisence et à l'explorateur d'objet
(mais il faut déclarer l'objet en early binding).


par exemple, pour essais avec WMI :

faut rajouter la référence
Microsoft WMI Scripting V 1.2 library

et déclarer l'objet ainsi :

Dim oReg As WbemScripting.SWbemObject
strOb >> "winmgmts:{impersonationLevel=impersonate,authenticationLevel=Connect}!\.rootdefault:StdRegProv"
Set oReg = GetObject(strOb)

Pour tout ceci, il est tout à fait possible d'utiliser Visual Basic 5
CCE, qui est gratuit.

@+
pascal

Bonjour,
Un dernier post à propos de VS .NET
J'ai trouvé comment éditer correctement un wsf avec toutes les
fonctionnalités intéressantes, y compris le late-binding avec
auto-complétion.

Voila :
Si je fais fichier nouveau Windows Script Host
J'obtiens ceci :

8<-------------------
<job id="main">
<script language="JScript">
WScript.Echo("JScript");
</script>

<script language="VBScript">
WScript.Echo "VBScript"
</script>
</job>
8<--------------------

Et l'éditeur me souligne job en m'indiquant : Le schéma actif ne
prend pas en charge l'élément 'job'
Pas très grave car tout fonctionne quand même (reconnaissance de
syntaxe, auto-complétion)

Il suffit en fait d'ajouter au début du fichier :
<package xmlns="http://schemas.microsoft.com/WindowsScriptHost">
et </package> en fin de fichier pour ne plus avoir les avertissements.

C'est dommage qu'on ne puisse exécuter à partir de l'environnement de
développement, mais on peut facilement ajouter un menu contextuel
'Déboguer' sous Windows en jouant avec les associations de fichier.
Il manque l'auto-complétion pour les objets déclarés dans une balise
<object>.
Dommage aussi que les boutons de mise en commentaire restent
obstinément grisés dans la barre d'outil édition.


Un point fort : on peut ajouter dans l'explorateur d'objet toutes les
références habituelles (Scripting.Runtime, etc ..), on peut ainsi
copier/coller le nom des classes et les références restent d'un
lancement à l'autre de l'environnement.

PS : je suis en VS .NET 2003.

Bonjour Fred

Si jamais tu songes a essayer VS pour éditer les scripts wsh (tu l'as
peut-être aussi).

Je ne l'ai pas réinstallé, cela est au gré de mon amploi du temps

J'ai modifié le modèle proposé pour un fichier wsh ainsi que le
fichier xsd qui décrit la syntaxe (uniquement la partie XML) d'un
script wsh (cela concerne les balises job, named, unnamed,
description, example, je n'ai pas ajouté usage dont je ne vois pas
l'utilité). Curieusement le fichier xsd fourni avec VS 2003 contient une
annotation de version 5.6 (la dernière de Windows Script Host je
crois) mais il manquait pas mal de choses. Je suis surpris.
Je les mets en pièce jointe. Il faut enlever l'extension txt. A
l'intérieur des fichiers, en commentaire, j'ai mis l'emplacement du
disque où se trouvent les originaux.

Merci, je garde ça de coté.

@+
pascal

Bonjour Jean

Heureux de te lire !

Moi itou :-)
Alors ... combien de ° à l'ombre en cette saison ? :-)

Merci de ta réponse, mais effectivement comme dit scraper, j'aurait voulu me
passer de l'objet WScript.Shell, (si toutefois cela était possible), car
j'utilise déjà l'objet
"winmgmts:{impersonationLevel=impersonate}!\.rootdefault:StdRegProv" pour
accéder au registre.

@+
pascal

Quelle est la solution pour avoir un chemin "exploitable" ?

Comme ceci ... ? :

'---8<---
DEMO

Sub DEMO
regval=_
"HKEY_CURRENT_USER"&_
"Identities"&_
"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"&_
"Software"&_
"Microsoft"&_
"Outlook Express"&_
"5.0"&_
"Store Root"

WScript.Echo Valeur_REG_EXPAND_SZ(regval)
End Sub

Function Valeur_REG_EXPAND_SZ(valeur)
Valeur_REG_EXPAND_SZ=""
On Error Resume Next
With CreateObject("WScript.Shell")
Valeur_REG_EXPAND_SZ=_
.ExpandEnvironmentStrings(.RegRead(valeur))
End With
On Error GoTo 0
End Function
'---8<---

Amicalement,

--
Jean - JMST
Belgium

Bonjour Jean


Désolé pour cette réponse tardive.

En cemoment, il fait en moyenne 20° mais nous avons eu un gros ennui la
semaine dernière avec beaucoup de mistral... et les feux de fôret s qui
débutent !

@+
pascal

Bonjour Jean

Heureux de te lire !

Moi itou :-)
Alors ... combien de ° à l'ombre en cette saison ? :-)

Merci de ta réponse, mais effectivement comme dit scraper, j'aurait
voulu me passer de l'objet WScript.Shell, (si toutefois cela était
possible), car j'utilise déjà l'objet
"winmgmts:{impersonationLevel=impersonate}!\.rootdefault:StdRegProv"
pour accéder au registre.

@+
pascal

Bonjour Paskal, dans le message
news:%23jaCqqLVFHA.2128@TK2MSFTNGP15.phx.gbl
tu disais :

Bonjour Jean


Désolé pour cette réponse tardive.

En cemoment, il fait en moyenne 20° mais nous avons eu un gros ennui
la semaine dernière avec beaucoup de mistral... et les feux de fôret
s qui débutent !

hier, il faisait plutôt 51 ° à l'ombre rofl

bon, je sors ...




--

Attention ! Adresse mail invalide ...
Pour me contacter, cliquez sur le lien ci-dessous:
http://scraper.chez.tiscali.fr/contact.htm

scraper