Rechercher tous les fichiers d'un SID donné*?

Bonjour à tous,

J'ai une question, je ne suis pas un spé******te de Windows. ;-)


Est-ce qu'il est possible de faire un script VBS pour rechercher et
lister sur un volume tous les fichiers et dossiers d'un SID donné (le
"truc" en S-1-5-21-1454471165-1004336348-1606980848-xxxx), si oui cela
a-t-il été déjà fait*?

Le but recherché est de "nettoyer" les ACL d'une installation "curieuse"
qui a laissé des fichiers ayant comme possesseur un utilisateur qui
n'existe plus sur la machine. Une partie ayant été fait "à la main" le
but en fait de rechercher les "fichiers oubliés".

Je n'ai pas trouvé là
<http://www.microsoft.com/technet/scriptcenter/default.mspx>, un peu
touffu pour moi, ni dans la cassette du sieur JC Bellamy
<http://www.bellamyjc.org/fr/vbsdownload.html>

D'avance merci.

P.S. suivi en fr.comp.os.ms-windows plus facile d'accès pour moi.

--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France

De: MezencevR
Bonjour,
Je crois que vous n'avez pas besoin de script ! Voyez, sur
http://www.hotline-pc.org/invite-de-...de/icacls.html. Il me semble que ICACLS
répond Ã* vos soucis. MR:-)

"Jacques Perrocheau" a écrit :

> Bonjour Ã* tous,
>
> J'ai une question, je ne suis pas un spé******te de Windows. ;-)
>
>
> Est-ce qu'il est possible de faire un script VBS pour rechercher et
> lister sur un volume tous les fichiers et dossiers d'un SID donné (le
> "truc" en S-1-5-21-1454471165-1004336348-1606980848-xxxx), si oui cela
> a-t-il été déjÃ* fait ?
>
> Le but recherché est de "nettoyer" les ACL d'une installation "curieuse"
> qui a laissé des fichiers ayant comme possesseur un utilisateur qui
> n'existe plus sur la machine. Une partie ayant été fait "Ã* la main" le
> but en fait de rechercher les "fichiers oubliés".
>
> Je n'ai pas trouvé lÃ*
> <http://www.microsoft.com/technet/scriptcenter/default.mspx>, un peu
> touffu pour moi, ni dans la cassette du sieur JC Bellamy
> <http://www.bellamyjc.org/fr/vbsdownload.html>
>
> D'avance merci.
>
> P.S. suivi en fr.comp.os.ms-windows plus facile d'accès pour moi.
>
> --
> Jacques PERROCHEAU
> CNRS UMR 6226
> Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
>

In article <DA5BC798-B377-4C07-93BD-CBA08CC4EC22@microsoft.com>,
MezencevR <MezencevR@discussions.microsoft.com> wrote:

> Je crois que vous n'avez pas besoin de script ! Voyez, sur
> http://www.hotline-pc.org/invite-de-...de/icacls.html. Il me semble que ICACLS
> répond Ã* vos soucis. MR:-)

OK, merci.

Un truc comme:

icacls Nom_Répertoire [/substitute Ancien_SID Nouveau_SID [...]]

si on peut le rendre récursif dans toute une hiérachie de dossiers
ferait peut-être l'affaire.

Encore faudrait-il que je sois assez malin pour faire fonctionner cet
"icalcs" dans une fenêtre d'"Invite de commande":

icacls test

'icalcs' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

J'ai sûrement loupé une marche.

Je ne suis même pas capable de faire l'exercice proposé en bas de la
page. ;-(.

--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France

Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> a écrit dans ce
message
<news:487f816f$0$24359$426a74cc@news.free.fr> :

> Encore faudrait-il que je sois assez malin pour faire fonctionner cet
> "icalcs" dans une fenêtre d'"Invite de commande":
>
> icacls test
>
> 'icalcs' n'est pas reconnu en tant que commande interne
> ou externe, un programme exécutable ou un fichier de commandes.
>
> J'ai sûrement loupé une marche.
>
> Je ne suis même pas capable de faire l'exercice proposé en bas de la
> page. ;-(.

Bonjour,

Comme toute commande, il faut qu'elle soit présente dans un dossier du
PATH afin que le système puisse la retrouver et l'exécuter depuis
n'importe quel dossier.

Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
nouveau dossier et d'ajouter ce dossier à la variable PATH. Ensuite, il
ne vous restera qu'à déplacer toutes vos commandes dans ce dossier pour
les rendre accessible depuis n'importe quel dossier.

http://www.ptorris.com/console.php#cmdpath

Exemple (depuis le dossier de cmdPATH) :
cmdpath c:\cmdpath

* crée le dossier "cmdpath" et l'ajoute au PATH utilisateur

NB : bien entendu, si la commande n'est pas accessible via le PATH (tel
cmdPath la première fois), il convient de l'exécuter à partir de son
propre dossier.

En complément : pour ajouter l'option "Invite de commandes" dans le
menu contextuel des dossiers (clic droit), vous pouvez utiliser RegDos
(compatible XP-Vista). Cela fait, 2 clics depuis l'Explorateur et vous
vous retrouvez sous l'invite de commandes dans le dossier souhaité :
http://www.ptorris.com/rapido.php#regdos

--
Bien à vous. Pierre TORRIS
www.ptorris.com

In article <mn.8cd27d872d8349be.87733@ptorris.com>,
Pierre TORRIS <contact_sur_site@ptorris.com> wrote:

> Comme toute commande, il faut qu'elle soit présente dans un dossier du
> PATH afin que le système puisse la retrouver et l'exécuter depuis
> n'importe quel dossier.

??? Qu'est-ce "un dossier du PATH"*? C'est pour moi une étrange façon de
désigner la variable d'environnement, "PATH".

Cela ne me dit pas où se trouve cet "icacls" qui si j'ai bien compris
existe quelque part sur le disque... et quel est la valeur de ce fameux
"PATH" à mettre.

Pourquoi donc des trucs existant dans une installation Windows ne sont
pas directement utilisables avec un minimum d'information comme la
lecture du help*que bien évidemment je n'arrive pas aussi à faire
apparaître*?

Pourquoi diable faut-il mettre les mains dans le cambouis, avant
utilisation dès qu'on sort un peu de l'ordinaire*?


> Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
> nouveau dossier et d'ajouter ce dossier à la variable PATH.

Je n'ai toujours pas bien saisi la finalité de ce que vous me proposez..
Visiblement le vocabulaire n'est pas le même dans les "autres mondes" ;-)

> Ensuite, il ne vous restera qu'à déplacer toutes vos commandes

??? Que désignez-vous par "commandes"*?

> dans ce dossier pour les rendre accessible depuis n'importe quel
> dossier.

Franchement je ne suis pas votre pensée, la commande icals (qui doit
être un exécutable planqué quelque part) doit bien accepter un chemin
pour désigner un répertoire ou un fichier et je me fous de savoir où
j'exécute icalcs.


> http://www.ptorris.com/console.php#cmdpath
>
> Exemple (depuis le dossier de cmdPATH) :
> cmdpath c:\cmdpath
>
> * crée le dossier "cmdpath" et l'ajoute au PATH utilisateur

Quand j'aurais compris ce que cela fait exactement, peut-être...

> NB : bien entendu, si la commande n'est pas accessible via le PATH (tel
> cmdPath la première fois), il convient de l'exécuter à partir de son
> propre dossier.

Pourquoi ne pas faire un minimum de help qui explique les fonctionnalité
et la mise en oeuvre...

SiteWeb.url
cmdPATH.exe

c'est court ;-(


> En complément : pour ajouter l'option "Invite de commandes" dans le
> menu contextuel des dossiers (clic droit), vous pouvez utiliser RegDos
> (compatible XP-Vista). Cela fait, 2 clics depuis l'Explorateur et vous
> vous retrouvez sous l'invite de commandes dans le dossier souhaité :
> http://www.ptorris.com/rapido.php#regdos

Là je saisis mieux l'objet et le but de votre "offre". j'ai compris que
cela permet d'ouvrir "Invite de commande" en faisant un "cd" qui amène
dans le répertoire désigné par la souris...

Comme j'utilise l'équivalent sur l'unix où je suis, je comprends mieux...

--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France

"Jacques Perrocheau" <Jacques.Perrocheau@univ-rennes1.fr> a écrit dans le
message de news: 4880571b$0$6133$426a74cc@news.free.fr...

>> * crée le dossier "cmdpath" et l'ajoute au PATH utilisateur
>
> Quand j'aurais compris ce que cela fait exactement, peut-être...

De deux choses l'une :

Ou bien toutes les commandes (programmes exécutables) sont regroupées
en un seul endroit fixe, ce qui est inimaginable pour des tas de raison
(dont
j'ai bien peur que vous vous foutiez également).

Ou bien, si on peut, pour des raisons d'organisation et de souplesse
(l'autre
monde, quoi), les mettre où l'on veut, alors il faut bien dire au système où
elles sont. Croyez-vous vraiment qu'une recherche sur tous vos disques
est lancée à chaque fois que vous lancez une commande ?
(euh, si ma femme lisait ça, elle mettrait moins de temps à trouver ses clés
à chaque fois, mais elle a l'excuse, elle, de ne pas être au CNRS).

La variable (chaîne textuelle) PATH énumère donc les quelques endroits
(chemin complet) où peuvent être trouvées des commandes.

Par conséquent, si je crée un dossier où je loge des commandes que j'ai
de bonnes raisons de ne pas mélanger à d'autres, je dois ensuite ajouter
ce dossier à la variable PATH.
La commande de Pierre Torris fait les deux à la fois : elle crée le dossier
*et* ajoute son chemin dans le PATH.

J'espère avoir contribué un peu à éclaircir les choses, surmontant le
découragement qui peut poindre en lisant quelqu'un qui affirme s'en
<citation>
foutre
</citation>
..

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Oberhoffen/Moder, France

Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> a écrit dans ce
message
<news:4880571b$0$6133$426a74cc@news.free.fr> :

> In article <mn.8cd27d872d8349be.87733@ptorris.com>,
> Pierre TORRIS <contact_sur_site@ptorris.com> wrote:
>
>> Comme toute commande, il faut qu'elle soit présente dans un dossier du
>> PATH afin que le système puisse la retrouver et l'exécuter depuis
>> n'importe quel dossier.
>
> ??? Qu'est-ce "un dossier du PATH"*? C'est pour moi une étrange façon de
> désigner la variable d'environnement, "PATH".

Ca ne désigne pas la variable en elle-même, mais son contenu !

La variable d'environnement "PATH" contient des noms de dossiers
(chemins complets). Chacun des chemins étant séparés par un point
virgule. Donc, un dossier du PATH est un dossier (chemin complet) qui
figure dans la variable d'environnement "PATH".

En invite de commandes, tapez (pour lister la contenu de la variable) :
path

> Cela ne me dit pas où se trouve cet "icacls" qui si j'ai bien compris
> existe quelque part sur le disque... et quel est la valeur de ce fameux
> "PATH" à mettre.

Je parlais de commandes (exécutables) ajoutées.

"icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".

Hors, ce dossier figure par défaut dans la variable "PATH". Si donc, le
fichier "icacls.exe" existe bien sur votre système dans le dossier
"system32", et que le chemin "%SystemRoot%\system32" existe bien dans
la variable "PATH", c'est qu'il est fort probable que votre soucis
provienne du fait que le type de la variable "PATH" soit erroné dans le
Registre. Chose que cmdPATH peut résoudre au passage (voir ci-dessous).

> Pourquoi donc des trucs existant dans une installation Windows ne sont
> pas directement utilisables avec un minimum d'information comme la
> lecture du help*que bien évidemment je n'arrive pas aussi à faire
> apparaître*?

Il faut aussi préciser qu'il y a différentes versions de Windows.
Toutes ne possèdent pas forcément les mêmes commandes de base.

> Pourquoi diable faut-il mettre les mains dans le cambouis, avant
> utilisation dès qu'on sort un peu de l'ordinaire*?

Il y a le système seul après son installation.
Et puis le système après moults installations tiers.

>> Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
>> nouveau dossier et d'ajouter ce dossier à la variable PATH.
>
> Je n'ai toujours pas bien saisi la finalité de ce que vous me proposez..
> Visiblement le vocabulaire n'est pas le même dans les "autres mondes" ;-)

Z'êtes de quel monde sinon... lol

>> Ensuite, il ne vous restera qu'à déplacer toutes vos commandes
>
> ??? Que désignez-vous par "commandes"*?

Une commande est un exécutable. Il y a les commandes d'origine, mais il
a aussi toutes les commandes que l'on peut ajouter. Si les commandes
d'origine se trouve dans les dossiers de Windows (qui se trouvent par
défaut dans la variable PATH), on préférera ajouter et centraliser les
nouvelles commandes dans un dossier créé pour l'occasion. Dossier que
l'on rajoutera à la variable PATH afin que ces nouvelles commandes
soient accessibles de partout, tout comme une commande d'origine.

Chose que réalise donc cmdPATH en 1 coup. ;-)

>> dans ce dossier pour les rendre accessible depuis n'importe quel
>> dossier.
>
> Franchement je ne suis pas votre pensée, la commande icals (qui doit
> être un exécutable planqué quelque part) doit bien accepter un chemin
> pour désigner un répertoire ou un fichier et je me fous de savoir où
> j'exécute icalcs.

Dans le cas présent, c'est le système qui se fout royalement de ce que
vous pouvez bien saisir, puisque (au choix) :

1) l'exécutable n'est pas présent
2) le chemin dans lequel il se trouve n'est pas présent dans le PATH
3) Le chemin est composé d'une variable d'environnement ne pouvant pas
être interprétée (expandée) - voir ci-bas.

Donc, si vous le voulez bien :

1) Vérifiez que "icacls.exe" figure dans "%SystemRoot%\system32"
2) Vérifiez que la variable "PATH" contienne ce chemin.
Tapez dans Exécuter (ou Rechercher) :
cmd /k path
3) Si oui, le type de la variable PATH doit être erroné (voir ci-bas)
En attendant, vous pouvez très bien exécuter "icacls.exe" ou
n'importe quelle autre commande en spéficiant son chemin d'accès :

%systemroot%\system32\icacls

>> http://www.ptorris.com/console.php#cmdpath
>>
>> Exemple (depuis le dossier de cmdPATH) :
>> cmdpath c:\cmdpath
>>
>> * crée le dossier "cmdpath" et l'ajoute au PATH utilisateur
>
> Quand j'aurais compris ce que cela fait exactement, peut-être...

Si ce n'est pas le cas, j'abandonne. :-)
Et si vous ne voulez pas rajouter de commandes, ce n'est pas la peine.

Lors de son usage, cmdPATH indique toutefois si le type de la variable
PATH est erroné dans le Registre (REG_SZ au lieu de REG_EXPAND_SZ).
Pour le vérifier et le corriger directement, il suffit d'utiliser la
syntaxe suivante :

cmdpath /r
cmdpath /k /r

Et oui, il y 2 syntaxes, car il y a en vérité 2 variables PATH ! Une
pour l'utilisateur (HKCU) et une pour la machine (HKLM) situées dans le
Registre sous les clés :

HKCU\Environment
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Dans votre cas, la seconde syntaxe serait essentielle puisqu'on trouve
"%SystemRoot%\system32" dans HKLM, qui ne peut être interprété qu'avec
le type "REG_EXPAND_SZ".

NB : à noter que ces syntaxes ne créent ni de dossier, ni ne modifie
les variables. Elles contrôlent le type des variables en permettant de
les corriger (réécrire) le cas échéant.

>> NB : bien entendu, si la commande n'est pas accessible via le PATH (tel
>> cmdPath la première fois), il convient de l'exécuter à partir de son
>> propre dossier.
>
> Pourquoi ne pas faire un minimum de help qui explique les fonctionnalité
> et la mise en oeuvre...
>
> SiteWeb.url
> cmdPATH.exe
>
> c'est court ;-(

Ce n'est pas une spécification qui concerne cmdPATH, mais Windows !!!!

Concernant le help de cmdPATH :
cmdpath /?

>> En complément : pour ajouter l'option "Invite de commandes" dans le
>> menu contextuel des dossiers (clic droit), vous pouvez utiliser RegDos
>> (compatible XP-Vista). Cela fait, 2 clics depuis l'Explorateur et vous
>> vous retrouvez sous l'invite de commandes dans le dossier souhaité :
>> http://www.ptorris.com/rapido.php#regdos
>
> Là je saisis mieux l'objet et le but de votre "offre". j'ai compris que
> cela permet d'ouvrir "Invite de commande" en faisant un "cd" qui amène
> dans le répertoire désigné par la souris...
>
> Comme j'utilise l'équivalent sur l'unix où je suis, je comprends mieux...

On va dire que pour la compréhension, ce serait ça. ;-)

En vérité, ça exécute depuis le menu contextuel de l'Explorateur
"cmd.exe" (l'interpréteur de commandes) avec le chemin dans lequel on
se trouve en paramètre. Exemple manuel depuis Exécuter :
cmd %systemroot%\system32

--
Bien à vous. Pierre TORRIS
www.ptorris.com

Alain Naigeon <anaigeon@free.fr> a écrit dans ce message
<news:ev6JjlL6IHA.2544@TK2MSFTNGP04.phx.gbl> :

> Par conséquent, si je crée un dossier où je loge des commandes que j'ai
> de bonnes raisons de ne pas mélanger à d'autres, je dois ensuite ajouter
> ce dossier à la variable PATH.
> La commande de Pierre Torris fait les deux à la fois : elle crée le dossier
> *et* ajoute son chemin dans le PATH.
>
> J'espère avoir contribué un peu à éclaircir les choses, surmontant le
> découragement qui peut poindre en lisant quelqu'un qui affirme s'en
> <citation>
> foutre
> </citation>

Merci Alain. :-)

--
Bien à vous. Pierre TORRIS
www.ptorris.com

Dans : news:mn.93117d87e7f502f9.87733@ptorris.com,
Pierre TORRIS écrivait :

> "icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".

Hélas, c'est là qu'est l'os Pierre. Je crains que icacls ne soit pas
disponible pour XP. En tous cas, je n'ai rien trouvé en téléchargement
chez MS.

--
Fred
foleide@free.fr

Bonjour,

Pierre TORRIS wrote:
> Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> a écrit dans
> ce message
> <news:4880571b$0$6133$426a74cc@news.free.fr> :
>
>> In article <mn.8cd27d872d8349be.87733@ptorris.com>,
>> Pierre TORRIS <contact_sur_site@ptorris.com> wrote:
>>
>>> Comme toute commande, il faut qu'elle soit présente dans un dossier
>>> du PATH afin que le système puisse la retrouver et l'exécuter depuis
>>> n'importe quel dossier.
>>
>> ??? Qu'est-ce "un dossier du PATH" ? C'est pour moi une étrange
>> façon de désigner la variable d'environnement, "PATH".
>
> Ca ne désigne pas la variable en elle-même, mais son contenu !
>
> La variable d'environnement "PATH" contient des noms de dossiers
> (chemins complets). Chacun des chemins étant séparés par un point
> virgule. Donc, un dossier du PATH est un dossier (chemin complet) qui
> figure dans la variable d'environnement "PATH".
>
> En invite de commandes, tapez (pour lister la contenu de la variable)
> : path
>
>> Cela ne me dit pas où se trouve cet "icacls" qui si j'ai bien compris
>> existe quelque part sur le disque... et quel est la valeur de ce
>> fameux "PATH" à mettre.
>
> Je parlais de commandes (exécutables) ajoutées.
>
> "icacls" figure, dans mon Vista Ultimate, dans le dossier "system32".
>
> Hors, ce dossier figure par défaut dans la variable "PATH". Si donc,
> le fichier "icacls.exe" existe bien sur votre système dans le dossier
> "system32", et que le chemin "%SystemRoot%\system32" existe bien dans
> la variable "PATH", c'est qu'il est fort probable que votre soucis
> provienne du fait que le type de la variable "PATH" soit erroné dans
> le Registre. Chose que cmdPATH peut résoudre au passage (voir
> ci-dessous).
>
>> Pourquoi donc des trucs existant dans une installation Windows ne
>> sont pas directement utilisables avec un minimum d'information comme
>> la lecture du help que bien évidemment je n'arrive pas aussi à faire
>> apparaître ?
>
> Il faut aussi préciser qu'il y a différentes versions de Windows.
> Toutes ne possèdent pas forcément les mêmes commandes de base.
>
>> Pourquoi diable faut-il mettre les mains dans le cambouis, avant
>> utilisation dès qu'on sort un peu de l'ordinaire ?
>
> Il y a le système seul après son installation.
> Et puis le système après moults installations tiers.
>
>>> Vous pourriez par exemple utiliser cmdPATH qui permet de créer un
>>> nouveau dossier et d'ajouter ce dossier à la variable PATH.
>>
>> Je n'ai toujours pas bien saisi la finalité de ce que vous me
>> proposez.. Visiblement le vocabulaire n'est pas le même dans les
>> "autres mondes" ;-)
>
> Z'êtes de quel monde sinon... lol
>
>>> Ensuite, il ne vous restera qu'à déplacer toutes vos commandes
>>
>> ??? Que désignez-vous par "commandes" ?
>
> Une commande est un exécutable. Il y a les commandes d'origine, mais
> il a aussi toutes les commandes que l'on peut ajouter. Si les
> commandes d'origine se trouve dans les dossiers de Windows (qui se
> trouvent par défaut dans la variable PATH), on préférera ajouter et
> centraliser les nouvelles commandes dans un dossier créé pour
> l'occasion. Dossier que l'on rajoutera à la variable PATH afin que
> ces nouvelles commandes soient accessibles de partout, tout comme une
> commande d'origine.
>
> Chose que réalise donc cmdPATH en 1 coup. ;-)
>
>>> dans ce dossier pour les rendre accessible depuis n'importe quel
>>> dossier.
>>
>> Franchement je ne suis pas votre pensée, la commande icals (qui doit
>> être un exécutable planqué quelque part) doit bien accepter un chemin
>> pour désigner un répertoire ou un fichier et je me fous de savoir où
>> j'exécute icalcs.
>
> Dans le cas présent, c'est le système qui se fout royalement de ce que
> vous pouvez bien saisir, puisque (au choix) :
>
> 1) l'exécutable n'est pas présent
> 2) le chemin dans lequel il se trouve n'est pas présent dans le PATH
> 3) Le chemin est composé d'une variable d'environnement ne pouvant pas
> être interprétée (expandée) - voir ci-bas.
>
> Donc, si vous le voulez bien :
>
> 1) Vérifiez que "icacls.exe" figure dans "%SystemRoot%\system32"
> 2) Vérifiez que la variable "PATH" contienne ce chemin.
> Tapez dans Exécuter (ou Rechercher) :
> cmd /k path
> 3) Si oui, le type de la variable PATH doit être erroné (voir ci-bas)
> En attendant, vous pouvez très bien exécuter "icacls.exe" ou
> n'importe quelle autre commande en spéficiant son chemin d'accès :
>
> %systemroot%\system32\icacls
>
>>> http://www.ptorris.com/console.php#cmdpath
>>>
>>> Exemple (depuis le dossier de cmdPATH) :
>>> cmdpath c:\cmdpath
>>>
>>> * crée le dossier "cmdpath" et l'ajoute au PATH utilisateur
>>
>> Quand j'aurais compris ce que cela fait exactement, peut-être...
>
> Si ce n'est pas le cas, j'abandonne. :-)
> Et si vous ne voulez pas rajouter de commandes, ce n'est pas la peine.
>
> Lors de son usage, cmdPATH indique toutefois si le type de la variable
> PATH est erroné dans le Registre (REG_SZ au lieu de REG_EXPAND_SZ).
> Pour le vérifier et le corriger directement, il suffit d'utiliser la
> syntaxe suivante :
>
> cmdpath /r
> cmdpath /k /r
>
> Et oui, il y 2 syntaxes, car il y a en vérité 2 variables PATH ! Une
> pour l'utilisateur (HKCU) et une pour la machine (HKLM) situées dans
> le Registre sous les clés :
>
> HKCU\Environment
> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
>
> Dans votre cas, la seconde syntaxe serait essentielle puisqu'on trouve
> "%SystemRoot%\system32" dans HKLM, qui ne peut être interprété qu'avec
> le type "REG_EXPAND_SZ".
>
> NB : à noter que ces syntaxes ne créent ni de dossier, ni ne modifie
> les variables. Elles contrôlent le type des variables en permettant de
> les corriger (réécrire) le cas échéant.
>
>>> NB : bien entendu, si la commande n'est pas accessible via le PATH
>>> (tel cmdPath la première fois), il convient de l'exécuter à partir
>>> de son propre dossier.
>>
>> Pourquoi ne pas faire un minimum de help qui explique les
>> fonctionnalité et la mise en oeuvre...
>>
>> SiteWeb.url
>> cmdPATH.exe
>>
>> c'est court ;-(
>
> Ce n'est pas une spécification qui concerne cmdPATH, mais Windows !!!!
>
> Concernant le help de cmdPATH :
> cmdpath /?
>
>>> En complément : pour ajouter l'option "Invite de commandes" dans le
>>> menu contextuel des dossiers (clic droit), vous pouvez utiliser
>>> RegDos (compatible XP-Vista). Cela fait, 2 clics depuis
>>> l'Explorateur et vous vous retrouvez sous l'invite de commandes
>>> dans le dossier souhaité : http://www.ptorris.com/rapido.php#regdos
>>
>> Là je saisis mieux l'objet et le but de votre "offre". j'ai compris
>> que cela permet d'ouvrir "Invite de commande" en faisant un "cd" qui
>> amène dans le répertoire désigné par la souris...
>>
>> Comme j'utilise l'équivalent sur l'unix où je suis, je comprends
>> mieux...
>
> On va dire que pour la compréhension, ce serait ça. ;-)
>
> En vérité, ça exécute depuis le menu contextuel de l'Explorateur
> "cmd.exe" (l'interpréteur de commandes) avec le chemin dans lequel on
> se trouve en paramètre. Exemple manuel depuis Exécuter :
> cmd %systemroot%\system32

Je m'excuse d'intervenir dans votre discussion pour une petite remarque
.. Votre interlocuteur est peut-être équipé de XP et icacls.exe bien que
fonctionnant sous XP n'est pas livré de base avec ce système.
Icacls.exe est livré avec Vista ou 2003 Serveur.
Cordialement,
jackr13