Vista a plusieurs commandes intéressantes pour le batching.
Par exemple, WAITFOR
Waitfor permet d'envoyer ou d'attendre un signal inter-processus. Donc
de synchroniser des instances de batchs.
Petit exemple. Enregistrez les deux batch suivants :
::fichier wreceiv.bat
@echo off
echo Avant attente
waitfor /T 3600 TACHE2FINIE
echo Attente terminée
::fichier wsend.bat
@echo off
echo Envoi...
waitfor /SI TACHE2FINIE
Ouvrez deux invites de commande (dans deux fenêtres différentes).
Dans la première, lancez wreceiv.bat ; le script se lance, et se met
en attente.
Dans la seconde, lancez wsend.bat ; le script se lance et rend la
main. Mais, cela à envoyé un signal, reçu par la première fenêtre, qui
peut ainsi terminer son attente.
Petite contrainte : un signal peut être surveillé depuis une seule
instance à la fois.
Vista a plusieurs commandes intéressantes pour le batching. Par exemple, WAITFOR
Très pratique pour synchroniser des applis sur des postes différents. Mais ça existe depuis windows 95 (dans un des sous dossiers du CD) ;-)
MCI \(ex do ré Mi chel la si do\) [MVP]
Salut !
Très pratique pour synchroniser des applis sur des postes différents. Mais ça existe depuis windows 95
Ne voudrais tu pas parler des anciens outils de scriptage des connexions réseau ? Je crois que le WAITFOR nouveau est assez différent : communication interprocessus locale, mais pas en réseau.
Je suppose qu'il passe par les messages windows ; mais, j'aimerais bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres logiciels (juste par curiosité).
Sinon, VISTA marque aussi le retour de FORFILES, Whoami, SetX, Choice, Timeout, Where, etc. et a beaucoup de nouveautés.
@+
Michel Claveau
Salut !
Très pratique pour synchroniser des applis sur des postes différents.
Mais ça existe depuis windows 95
Ne voudrais tu pas parler des anciens outils de scriptage des connexions
réseau ?
Je crois que le WAITFOR nouveau est assez différent : communication
interprocessus locale, mais pas en réseau.
Je suppose qu'il passe par les messages windows ; mais, j'aimerais bien
savoir lequel, pour pouvoir synchroniser des batchs avec d'autres
logiciels (juste par curiosité).
Sinon, VISTA marque aussi le retour de FORFILES, Whoami, SetX, Choice,
Timeout, Where, etc. et a beaucoup de nouveautés.
Très pratique pour synchroniser des applis sur des postes différents. Mais ça existe depuis windows 95
Ne voudrais tu pas parler des anciens outils de scriptage des connexions réseau ? Je crois que le WAITFOR nouveau est assez différent : communication interprocessus locale, mais pas en réseau.
Je suppose qu'il passe par les messages windows ; mais, j'aimerais bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres logiciels (juste par curiosité).
Sinon, VISTA marque aussi le retour de FORFILES, Whoami, SetX, Choice, Timeout, Where, etc. et a beaucoup de nouveautés.
@+
Michel Claveau
Gilles RONSIN
"MCI (ex do ré Mi chel la si do) [MVP]" , le ven. 07 déc. 2007 08:53:54, écrivait ceci:
Salut ! Yo !
Très pratique pour synchroniser des applis sur des postes différents. Mais ça existe depuis windows 95
Ne voudrais tu pas parler des anciens outils de scriptage des connexions réseau ? Je crois que le WAITFOR nouveau est assez différent : communication interprocessus locale, mais pas en réseau. Tu as excité ma curiosité :-)
------------------------------------------------------------------ WaitFor fonctionne de deux façons :
Syntaxe 1 : pour envoyer un signal WAITFOR [/S système [/U utilisateur [/P [mot_de_passe]]]] /SI signal
Syntaxe 2 : pour attendre un signal WAITFOR [/T délai_maximal] signal
Description : Cet outil envoie, ou attend, un signal sur un ordinateur. Si /S n'est pas spécifié, le signal est envoyé à tous les ordinateurs dans le domaine. Si /S est spécifié, le signal n'est envoyé qu'à l'ordinateur spécifié. --------------------------------------------------------------------- Donc c'est bien la même fonctionnalité que l'ancien WAITFOR (avec des options supplémentaires comme préciser la cible du signal).
Je suppose qu'il passe par les messages windows ; mais, j'aimerais bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres logiciels (juste par curiosité).
A l'époque, il passait par un message NetBIOS je crois. J'avais fait une page avec des exemples (tiens ce n'est pas W95 mais W98 l'apparition) http://gilles.ronsin.free.fr/#waitfor
Sinon, VISTA marque aussi le retour de FORFILES, Whoami, SetX, Choice, Timeout, Where, etc. et a beaucoup de nouveautés.
Va falloir que j'aille faire une opération de reconnaissance alors. ;-)
"MCI (ex do ré Mi chel la si do) [MVP]"
<enleverlesO.OmcO@OmclaveauO.com>, le ven. 07 déc. 2007 08:53:54,
écrivait ceci:
Salut !
Yo !
Très pratique pour synchroniser des applis sur des postes
différents. Mais ça existe depuis windows 95
Ne voudrais tu pas parler des anciens outils de scriptage des
connexions réseau ?
Je crois que le WAITFOR nouveau est assez différent :
communication interprocessus locale, mais pas en réseau.
Tu as excité ma curiosité :-)
------------------------------------------------------------------
WaitFor fonctionne de deux façons :
Syntaxe 1 : pour envoyer un signal
WAITFOR [/S système [/U utilisateur [/P [mot_de_passe]]]] /SI
signal
Syntaxe 2 : pour attendre un signal
WAITFOR [/T délai_maximal] signal
Description :
Cet outil envoie, ou attend, un signal sur un ordinateur. Si /S
n'est pas
spécifié, le signal est envoyé à tous les ordinateurs dans le
domaine. Si /S est spécifié, le signal n'est envoyé qu'à
l'ordinateur spécifié.
---------------------------------------------------------------------
Donc c'est bien la même fonctionnalité que l'ancien WAITFOR (avec des
options supplémentaires comme préciser la cible du signal).
Je suppose qu'il passe par les messages windows ; mais, j'aimerais
bien savoir lequel, pour pouvoir synchroniser des batchs avec
d'autres logiciels (juste par curiosité).
A l'époque, il passait par un message NetBIOS je crois. J'avais fait
une page avec des exemples (tiens ce n'est pas W95 mais W98
l'apparition)
http://gilles.ronsin.free.fr/#waitfor
Sinon, VISTA marque aussi le retour de FORFILES, Whoami, SetX,
Choice, Timeout, Where, etc. et a beaucoup de nouveautés.
Va falloir que j'aille faire une opération de reconnaissance alors.
;-)
"MCI (ex do ré Mi chel la si do) [MVP]" , le ven. 07 déc. 2007 08:53:54, écrivait ceci:
Salut ! Yo !
Très pratique pour synchroniser des applis sur des postes différents. Mais ça existe depuis windows 95
Ne voudrais tu pas parler des anciens outils de scriptage des connexions réseau ? Je crois que le WAITFOR nouveau est assez différent : communication interprocessus locale, mais pas en réseau. Tu as excité ma curiosité :-)
------------------------------------------------------------------ WaitFor fonctionne de deux façons :
Syntaxe 1 : pour envoyer un signal WAITFOR [/S système [/U utilisateur [/P [mot_de_passe]]]] /SI signal
Syntaxe 2 : pour attendre un signal WAITFOR [/T délai_maximal] signal
Description : Cet outil envoie, ou attend, un signal sur un ordinateur. Si /S n'est pas spécifié, le signal est envoyé à tous les ordinateurs dans le domaine. Si /S est spécifié, le signal n'est envoyé qu'à l'ordinateur spécifié. --------------------------------------------------------------------- Donc c'est bien la même fonctionnalité que l'ancien WAITFOR (avec des options supplémentaires comme préciser la cible du signal).
Je suppose qu'il passe par les messages windows ; mais, j'aimerais bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres logiciels (juste par curiosité).
A l'époque, il passait par un message NetBIOS je crois. J'avais fait une page avec des exemples (tiens ce n'est pas W95 mais W98 l'apparition) http://gilles.ronsin.free.fr/#waitfor
Sinon, VISTA marque aussi le retour de FORFILES, Whoami, SetX, Choice, Timeout, Where, etc. et a beaucoup de nouveautés.
Va falloir que j'aille faire une opération de reconnaissance alors. ;-)
Méta-MCI \(MVP\)
Bonsoir, Gilles !
J'avions point vu le fonctionnement en réseau. Merci de m'avoir ouvert les yeux.
Alors, ça marche (je viens de tester, entre deux machines virtuelles). Mais, j'ai été obligé d'utiliser /S adresseIP pour spécifier l'ordinateur "receveur".
Et puis, aussi, ça fonctionne en interactif (ça peut être utile).
Bonne nuit.
MCI
Bonsoir, Gilles !
J'avions point vu le fonctionnement en réseau. Merci de m'avoir ouvert
les yeux.
Alors, ça marche (je viens de tester, entre deux machines virtuelles).
Mais, j'ai été obligé d'utiliser /S adresseIP pour spécifier
l'ordinateur "receveur".
Et puis, aussi, ça fonctionne en interactif (ça peut être utile).
J'avions point vu le fonctionnement en réseau. Merci de m'avoir ouvert les yeux.
Alors, ça marche (je viens de tester, entre deux machines virtuelles). Mais, j'ai été obligé d'utiliser /S adresseIP pour spécifier l'ordinateur "receveur".
Et puis, aussi, ça fonctionne en interactif (ça peut être utile).
Bonne nuit.
MCI
Gilles LAURENT [MVP]
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news: | Salut !
Bonsoir,
| Je suppose qu'il passe par les messages windows ; mais, j'aimerais | bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres | logiciels (juste par curiosité).
La technologie IPC utilisée par l'outil waitfor.exe est le mailslot (datagramme). Pour envoyer un signal, il suffit d'écrire une chaîne de caractères quelconque dans le mailslot. Par exemple, pour envoyer le signal "alert" à l'ordinateur local en attente de ce même signal, il suffit d'écrire une chaîne de caractère dans le mailslot suivant : .mailslotwaitfor.exealert
Pour envoyer le signal "alert" à l'ordinateur local en VBScript :
--- Coupez ici : WriteToMailslot.vbs --- Set oFs=CreateObject("Scripting.FileSystemObject") Set oMailslot=oFs.CreateTextFile(".mailslotwaitfor.exealert") oMailslot.WriteLine --- Coupez ici : WriteToMailslot.vbs ---
Note: Aucune vérification n'est effectuée par l'outil waitfor.exe concernant le message (datagramme) transmis :-( Pour cette raison, je n'utilise jamais cet outil dans un environnement de production.
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"MCI (ex do ré Mi chel la si do) [MVP]"
<enleverlesO.OmcO@OmclaveauO.com> a écrit dans le message de
news:etL9gZKOIHA.3940@TK2MSFTNGP05.phx.gbl
| Salut !
Bonsoir,
| Je suppose qu'il passe par les messages windows ; mais, j'aimerais
| bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres
| logiciels (juste par curiosité).
La technologie IPC utilisée par l'outil waitfor.exe est le mailslot
(datagramme). Pour envoyer un signal, il suffit d'écrire une chaîne de
caractères quelconque dans le mailslot. Par exemple, pour envoyer le
signal "alert" à l'ordinateur local en attente de ce même signal, il
suffit d'écrire une chaîne de caractère dans le mailslot suivant :
\.mailslotwaitfor.exealert
Pour envoyer le signal "alert" à l'ordinateur local en VBScript :
--- Coupez ici : WriteToMailslot.vbs ---
Set oFs=CreateObject("Scripting.FileSystemObject")
Set oMailslot=oFs.CreateTextFile("\.mailslotwaitfor.exealert")
oMailslot.WriteLine
--- Coupez ici : WriteToMailslot.vbs ---
Note: Aucune vérification n'est effectuée par l'outil waitfor.exe
concernant le message (datagramme) transmis :-( Pour cette raison, je
n'utilise jamais cet outil dans un environnement de production.
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news: | Salut !
Bonsoir,
| Je suppose qu'il passe par les messages windows ; mais, j'aimerais | bien savoir lequel, pour pouvoir synchroniser des batchs avec d'autres | logiciels (juste par curiosité).
La technologie IPC utilisée par l'outil waitfor.exe est le mailslot (datagramme). Pour envoyer un signal, il suffit d'écrire une chaîne de caractères quelconque dans le mailslot. Par exemple, pour envoyer le signal "alert" à l'ordinateur local en attente de ce même signal, il suffit d'écrire une chaîne de caractère dans le mailslot suivant : .mailslotwaitfor.exealert
Pour envoyer le signal "alert" à l'ordinateur local en VBScript :
--- Coupez ici : WriteToMailslot.vbs --- Set oFs=CreateObject("Scripting.FileSystemObject") Set oMailslot=oFs.CreateTextFile(".mailslotwaitfor.exealert") oMailslot.WriteLine --- Coupez ici : WriteToMailslot.vbs ---
Note: Aucune vérification n'est effectuée par l'outil waitfor.exe concernant le message (datagramme) transmis :-( Pour cette raison, je n'utilise jamais cet outil dans un environnement de production.
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
La technologie IPC utilisée par l'outil waitfor.exe est le mailslot (datagramme). Pour envoyer un signal, il suffit d'écrire Je ne connaissait pas cette technologie.
Note: Aucune vérification n'est effectuée par l'outil waitfor.exe concernant le message (datagramme) transmis :-( Pour cette raison, je n'utilise jamais cet outil dans un environnement de production.
Ca peut toutefois toujours rendre des petits services.
La technologie IPC utilisée par l'outil waitfor.exe est le
mailslot (datagramme). Pour envoyer un signal, il suffit d'écrire
Je ne connaissait pas cette technologie.
Note: Aucune vérification n'est effectuée par l'outil waitfor.exe
concernant le message (datagramme) transmis :-( Pour cette raison,
je n'utilise jamais cet outil dans un environnement de production.
Ca peut toutefois toujours rendre des petits services.
La technologie IPC utilisée par l'outil waitfor.exe est le mailslot (datagramme). Pour envoyer un signal, il suffit d'écrire Je ne connaissait pas cette technologie.
Note: Aucune vérification n'est effectuée par l'outil waitfor.exe concernant le message (datagramme) transmis :-( Pour cette raison, je n'utilise jamais cet outil dans un environnement de production.
Ca peut toutefois toujours rendre des petits services.
Alors, ça marche (je viens de tester, entre deux machines virtuelles). Mais, j'ai été obligé d'utiliser /S adresseIP pour spécifier l'ordinateur "receveur".
A part l'extinction d'un parc en réseau je n'ai pourtant pas trouvé beaucoup d'applications.
Alors, ça marche (je viens de tester, entre deux machines
virtuelles). Mais, j'ai été obligé d'utiliser /S adresseIP pour
spécifier l'ordinateur "receveur".
A part l'extinction d'un parc en réseau je n'ai pourtant pas trouvé
beaucoup d'applications.
Alors, ça marche (je viens de tester, entre deux machines virtuelles). Mais, j'ai été obligé d'utiliser /S adresseIP pour spécifier l'ordinateur "receveur".
A part l'extinction d'un parc en réseau je n'ai pourtant pas trouvé beaucoup d'applications.
Bonne nuit. merci toi aussi
Méta-MCI \(MVP\)
Bonjour (maître de philosophie) Gilles !
Moi non plus, je ne connaissais pas MailSlot.
J'ai cherché un peu, et j'ai vu que c'était que c'était déjà utilisé dans le vieux Winpopup.
"Par ma foi ! il y a plus de quarante ans que je dis du mailslot sans que j'en susse rien, et je vous suis le plus obligé du monde de m'avoir appris cela." - Monsieur Joudain/MCI - (d'où le surnom de l'introduction).
Sinon, j'ai lu que mailslot utilisait SMB et UDP. Est-ce ce dernier point qui te pousse à ne pas l'utiliser en production ? Parce que UDP n'a pas les mécanismes de contrôle de délivrance des paquets ? Mais, c'est la contrepartie d'une plus grande rapidité, et d'une moins grande consommation de bande passante. Et puis, en TCP, il y a aussi des cas où ça bloque (par exemple, si la machine qui doit émettre le signal est (brutalement) bloquée, rebootée, déconnectée).
En tout cas, encore un truc à explorer...
@-salutations -- Michel Claveau
Bonjour (maître de philosophie) Gilles !
Moi non plus, je ne connaissais pas MailSlot.
J'ai cherché un peu, et j'ai vu que c'était que c'était déjà utilisé
dans le vieux Winpopup.
"Par ma foi ! il y a plus de quarante ans que je dis du mailslot sans
que j'en susse rien, et je vous suis le plus obligé du monde de m'avoir
appris cela." - Monsieur Joudain/MCI - (d'où le surnom de
l'introduction).
Sinon, j'ai lu que mailslot utilisait SMB et UDP. Est-ce ce dernier
point qui te pousse à ne pas l'utiliser en production ? Parce que UDP
n'a pas les mécanismes de contrôle de délivrance des paquets ? Mais,
c'est la contrepartie d'une plus grande rapidité, et d'une moins grande
consommation de bande passante. Et puis, en TCP, il y a aussi des cas où
ça bloque (par exemple, si la machine qui doit émettre le signal est
(brutalement) bloquée, rebootée, déconnectée).
J'ai cherché un peu, et j'ai vu que c'était que c'était déjà utilisé dans le vieux Winpopup.
"Par ma foi ! il y a plus de quarante ans que je dis du mailslot sans que j'en susse rien, et je vous suis le plus obligé du monde de m'avoir appris cela." - Monsieur Joudain/MCI - (d'où le surnom de l'introduction).
Sinon, j'ai lu que mailslot utilisait SMB et UDP. Est-ce ce dernier point qui te pousse à ne pas l'utiliser en production ? Parce que UDP n'a pas les mécanismes de contrôle de délivrance des paquets ? Mais, c'est la contrepartie d'une plus grande rapidité, et d'une moins grande consommation de bande passante. Et puis, en TCP, il y a aussi des cas où ça bloque (par exemple, si la machine qui doit émettre le signal est (brutalement) bloquée, rebootée, déconnectée).
En tout cas, encore un truc à explorer...
@-salutations -- Michel Claveau
Méta-MCI \(MVP\)
Salut !
En fait, j'en aurais une utilisation immédiate, chez un client où j'ai mis en place des procédures assez compliquées de sauvegardes et archivages : des postes sauvegardent certains répertoire sur un serveur, qui réalise un archivage, mais après avoir vérifié certaines tables, et avoir attendu la fin des sauvegardes des postes, et avant de faire une sauvegarde sur un autre serveur. Tout ça en batch (merci Robocopy).
Pour synchroniser Waitfor serait bien pratique... s'il existait sur toutes les machines concernées. Ce qui n'est pas le cas. D'où mon conditionnel du début.
Alors, soit je vais chercher à l'implémenter, là où ça manque, soit je vais attendre que les clients aient migré vers Vista + Server-2008 (qui a aussi Waitfor).
@-salutations -- Michel Claveau
Salut !
En fait, j'en aurais une utilisation immédiate, chez un client où j'ai
mis en place des procédures assez compliquées de sauvegardes et
archivages : des postes sauvegardent certains répertoire sur un serveur,
qui réalise un archivage, mais après avoir vérifié certaines tables, et
avoir attendu la fin des sauvegardes des postes, et avant de faire une
sauvegarde sur un autre serveur. Tout ça en batch (merci Robocopy).
Pour synchroniser Waitfor serait bien pratique... s'il existait sur
toutes les machines concernées. Ce qui n'est pas le cas. D'où mon
conditionnel du début.
Alors, soit je vais chercher à l'implémenter, là où ça manque, soit je
vais attendre que les clients aient migré vers Vista + Server-2008 (qui
a aussi Waitfor).
En fait, j'en aurais une utilisation immédiate, chez un client où j'ai mis en place des procédures assez compliquées de sauvegardes et archivages : des postes sauvegardent certains répertoire sur un serveur, qui réalise un archivage, mais après avoir vérifié certaines tables, et avoir attendu la fin des sauvegardes des postes, et avant de faire une sauvegarde sur un autre serveur. Tout ça en batch (merci Robocopy).
Pour synchroniser Waitfor serait bien pratique... s'il existait sur toutes les machines concernées. Ce qui n'est pas le cas. D'où mon conditionnel du début.
Alors, soit je vais chercher à l'implémenter, là où ça manque, soit je vais attendre que les clients aient migré vers Vista + Server-2008 (qui a aussi Waitfor).
Pour synchroniser Waitfor serait bien pratique... s'il existait sur toutes les machines concernées. Ce qui n'est pas le cas. D'où mon conditionnel du début.
Il y a de fortes chances qu'il soit compatible. Ca vaut le coup d'essayer. Sinon la version de W98....
Pour synchroniser Waitfor serait bien pratique... s'il existait
sur toutes les machines concernées. Ce qui n'est pas le cas. D'où
mon conditionnel du début.
Il y a de fortes chances qu'il soit compatible. Ca vaut le coup
d'essayer. Sinon la version de W98....
Pour synchroniser Waitfor serait bien pratique... s'il existait sur toutes les machines concernées. Ce qui n'est pas le cas. D'où mon conditionnel du début.
Il y a de fortes chances qu'il soit compatible. Ca vaut le coup d'essayer. Sinon la version de W98....
