Dans un fichier .bat, je fais une boucle for, soit
for %%c in (*.*) do unique c:%%c d:%%c
Si j'appelle le fichier .bat directement, la fonction trouve bien
les fichiers et effectue la commande désirée. Mais si j'appelle
le fichier .bat à l'intérieur d'un autre fichier .bat, cela
fonctionne parfois.
J'essaie de faire le script travail.bat avec ces commandes
call u toto
call u toto2
call u toto3
u.bat change les noms des répertoires et cela marche bien si je
fais des pause, par exemple :
cd c:%1
cd d:%1
call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ
95% des cas.
Et si je sélectionne manuellement les dossiers et que j'appelle
directement u2, alors cela marche tout le temps.
Quelqu'un a une idée du problème ?
C'est un PC avec 512 Mo de RAM. La commande mem me renseigne ainsi :
>mem
Type de mémoire Totale Utilisée Libre
---------------- -------- -------- --------
Conventionnelle 632K 65K 567K
Supérieure 0K 0K 0K
Réservée 0K 0K 0K
Étendue (XMS) 65 535K ? 522 996K
---------------- -------- -------- --------
Mémoire totale 66 167K ? 523 563K
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
$kymoi#
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
for %%c in (*.*) do unique c:%%c d:%%c
Si j'appelle le fichier .bat directement, la fonction trouve bien les fichiers et effectue la commande désirée. Mais si j'appelle le fichier .bat à l'intérieur d'un autre fichier .bat, cela fonctionne parfois. > J'essaie de faire le script travail.bat avec ces commandes
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
Et si je sélectionne manuellement les dossiers et que j'appelle directement u2, alors cela marche tout le temps.
Quelqu'un a une idée du problème ?
C'est un PC avec 512 Mo de RAM. La commande mem me renseigne ainsi :
>mem
Type de mémoire Totale Utilisée Libre ---------------- -------- -------- -------- Conventionnelle 632K 65K 567K Supérieure 0K 0K 0K Réservée 0K 0K 0K Étendue (XMS) 65 535K ? 522 996K ---------------- -------- -------- -------- Mémoire totale 66 167K ? 523 563K
Taille maximale du programme exécutable 567K (580 576 octets) Taille max. de la mémoire supérieure libre 0K (0 octets) MS-DOS réside en mémoire haute (HMA).
Il y a donc suffisamment d'espace mémoire.
Denis
Un fichier .bat intégré dans un fichier principal .bat ne rend
pas la main au fichier principal (fichier lancé en premier)
Pour être plus clair si dans le fichier que tu lances en premier,
par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat",
ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier
"toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des
instructions
à exécuter après "toto2.bat , elle ne le seront pas.
Depuis la version DOS 3.3, il existe une possibilité :
Faire précéder chaque fichier .bat intégré dans un fichier principal
de l'instruction CALL
Exemple : call toto2.bat
Une fois le contenu de ce fichier exécuté le système reviendra à la suite
des instructions
du fichier de départ "toto1.bat".
for %%c in (*.*) do unique c:%%c d:%%c
Si j'appelle le fichier .bat directement, la fonction trouve bien
les fichiers et effectue la commande désirée. Mais si j'appelle
le fichier .bat à l'intérieur d'un autre fichier .bat, cela
fonctionne parfois.
> J'essaie de faire le script travail.bat avec ces commandes
call u toto
call u toto2
call u toto3
u.bat change les noms des répertoires et cela marche bien si je
fais des pause, par exemple :
cd c:%1
cd d:%1
call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ
95% des cas.
Et si je sélectionne manuellement les dossiers et que j'appelle
directement u2, alors cela marche tout le temps.
Quelqu'un a une idée du problème ?
C'est un PC avec 512 Mo de RAM. La commande mem me renseigne ainsi :
>mem
Type de mémoire Totale Utilisée Libre
---------------- -------- -------- --------
Conventionnelle 632K 65K 567K
Supérieure 0K 0K 0K
Réservée 0K 0K 0K
Étendue (XMS) 65 535K ? 522 996K
---------------- -------- -------- --------
Mémoire totale 66 167K ? 523 563K
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
for %%c in (*.*) do unique c:%%c d:%%c
Si j'appelle le fichier .bat directement, la fonction trouve bien les fichiers et effectue la commande désirée. Mais si j'appelle le fichier .bat à l'intérieur d'un autre fichier .bat, cela fonctionne parfois. > J'essaie de faire le script travail.bat avec ces commandes
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
Et si je sélectionne manuellement les dossiers et que j'appelle directement u2, alors cela marche tout le temps.
Quelqu'un a une idée du problème ?
C'est un PC avec 512 Mo de RAM. La commande mem me renseigne ainsi :
>mem
Type de mémoire Totale Utilisée Libre ---------------- -------- -------- -------- Conventionnelle 632K 65K 567K Supérieure 0K 0K 0K Réservée 0K 0K 0K Étendue (XMS) 65 535K ? 522 996K ---------------- -------- -------- -------- Mémoire totale 66 167K ? 523 563K
Taille maximale du programme exécutable 567K (580 576 octets) Taille max. de la mémoire supérieure libre 0K (0 octets) MS-DOS réside en mémoire haute (HMA).
Il y a donc suffisamment d'espace mémoire.
Denis
Denis Beauregard
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr> écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
voir mon message...
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr>
écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend
pas la main au fichier principal (fichier lancé en premier)
Pour être plus clair si dans le fichier que tu lances en premier,
par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat",
ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier
"toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des
instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas.
Depuis la version DOS 3.3, il existe une possibilité :
Faire précéder chaque fichier .bat intégré dans un fichier principal
de l'instruction CALL
Exemple : call toto2.bat
Une fois le contenu de ce fichier exécuté le système reviendra à la suite
des instructions
du fichier de départ "toto1.bat".
voir mon message...
call u toto
call u toto2
call u toto3
u.bat change les noms des répertoires et cela marche bien si je
fais des pause, par exemple :
cd c:%1
cd d:%1
call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ
95% des cas.
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr> écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
voir mon message...
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Tonio - le Yéti
> Denis Beauregard nous a écrit dans son message :
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr> écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
voir mon message...
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le nombre de "files" ou "stacks" dans le contexte dos (config.sys) peut-être ? Dans quel cas cela ne fonctionne pas (tes 5% restants) ?
> Denis Beauregard nous a écrit dans son message :
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr>
écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend
pas la main au fichier principal (fichier lancé en premier)
Pour être plus clair si dans le fichier que tu lances en premier,
par exemple "toto1.bat" et que dans ce fichier tu intégres
"toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas
la main au fichier "toto1.bat". Si dans le fichier de lancement
"toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas.
Depuis la version DOS 3.3, il existe une possibilité :
Faire précéder chaque fichier .bat intégré dans un fichier principal
de l'instruction CALL
Exemple : call toto2.bat
Une fois le contenu de ce fichier exécuté le système reviendra à la
suite des instructions
du fichier de départ "toto1.bat".
voir mon message...
call u toto
call u toto2
call u toto3
u.bat change les noms des répertoires et cela marche bien si je
fais des pause, par exemple :
cd c:%1
cd d:%1
call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ
95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le nombre de "files" ou "stacks" dans le contexte dos (config.sys) peut-être
?
Dans quel cas cela ne fonctionne pas (tes 5% restants) ?
> Denis Beauregard nous a écrit dans son message :
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr> écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
voir mon message...
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le nombre de "files" ou "stacks" dans le contexte dos (config.sys) peut-être ? Dans quel cas cela ne fonctionne pas (tes 5% restants) ?
Le Sat, 23 Aug 2008 20:33:51 +0200, "Tonio - le Yéti" écrivait dans microsoft.public.fr.windows98:
Denis Beauregard nous a écrit dans son message :
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr> écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
voir mon message...
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le nombre de "files" ou "stacks" dans le contexte dos (config.sys) peut-être ?
Peut-être
Dans quel cas cela ne fonctionne pas (tes 5% restants) ?
Cela fait un bout que j'ai fait ce travail et je recommencerai dans plusieurs mois.
Ceci dit, je n'ai pas l'impression qu'il s'agit d'un problème de configuration car il y a des fichiers dont le nom est aussi long et qui passent sans difficulté. C'est peut-être lié au ~ des noms longs.
La prochaine fois, j'essaierai de réduire la longueur des noms pour voir si cela change quelque chose, et aussi de changer le config.sys. Je garde ce message comme non lu pour m'en rappeler !
Denis
Bonjour,
Je me souviens avoir posé en 2005 une question sur l'équivalent de la commande unix "wait" car j'avais des problèmes qui me semblaient liés au fait que certains ordres n'avaient pas le temps de s'éxécuter (un effet pervers du multi-tâche?). JC Bellamy m'avait à l'époque orienté vers le paramètre /wait dans mes fichiers.Bat (le texte exact ci-après).
[début]
Le but est de pouvoir lancer à la suite deux programmes suffisament incompatibles pour refuser de fonctionner ensemble.
Dans ce cas, il suffit de créer un simple batch, avec la commande START suivie du commutateur /WAIT !
@echo off start /wait appli1 start /wait appli2 ....
Avec "/wait", le passage à la ligne suivante n'a lieu que si l'appli ainsi lancée est terminée...
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
[Fin]
Peut-être est-ce une piste à creuser ?
Jacques
Denis Beauregard a écrit :
Le Sat, 23 Aug 2008 20:33:51 +0200, "Tonio - le Yéti"
<tonio@wanadaube.fr> écrivait dans microsoft.public.fr.windows98:
Denis Beauregard nous a écrit dans son message :
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr>
écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend
pas la main au fichier principal (fichier lancé en premier)
Pour être plus clair si dans le fichier que tu lances en premier,
par exemple "toto1.bat" et que dans ce fichier tu intégres
"toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas
la main au fichier "toto1.bat". Si dans le fichier de lancement
"toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas.
Depuis la version DOS 3.3, il existe une possibilité :
Faire précéder chaque fichier .bat intégré dans un fichier principal
de l'instruction CALL
Exemple : call toto2.bat
Une fois le contenu de ce fichier exécuté le système reviendra à la
suite des instructions
du fichier de départ "toto1.bat".
voir mon message...
call u toto
call u toto2
call u toto3
u.bat change les noms des répertoires et cela marche bien si je
fais des pause, par exemple :
cd c:%1
cd d:%1
call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ
95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le nombre de "files" ou "stacks" dans le contexte dos (config.sys) peut-être
?
Peut-être
Dans quel cas cela ne fonctionne pas (tes 5% restants) ?
Cela fait un bout que j'ai fait ce travail et je recommencerai dans
plusieurs mois.
Ceci dit, je n'ai pas l'impression qu'il s'agit d'un problème de
configuration car il y a des fichiers dont le nom est aussi long et
qui passent sans difficulté. C'est peut-être lié au ~ des noms longs.
La prochaine fois, j'essaierai de réduire la longueur des noms pour
voir si cela change quelque chose, et aussi de changer le config.sys.
Je garde ce message comme non lu pour m'en rappeler !
Denis
Bonjour,
Je me souviens avoir posé en 2005 une question sur l'équivalent de la
commande unix "wait" car j'avais des problèmes qui me semblaient liés au
fait que certains ordres n'avaient pas le temps de s'éxécuter (un effet
pervers du multi-tâche?). JC Bellamy m'avait à l'époque orienté vers le
paramètre /wait dans mes fichiers.Bat (le texte exact ci-après).
[début]
Le but est de pouvoir lancer à la suite deux programmes suffisament
incompatibles pour refuser de fonctionner ensemble.
Dans ce cas, il suffit de créer un simple batch, avec la commande START
suivie du commutateur /WAIT !
@echo off
start /wait appli1
start /wait appli2
....
Avec "/wait", le passage à la ligne suivante n'a lieu que si l'appli ainsi
lancée est terminée...
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Le Sat, 23 Aug 2008 20:33:51 +0200, "Tonio - le Yéti" écrivait dans microsoft.public.fr.windows98:
Denis Beauregard nous a écrit dans son message :
Le Tue, 15 Jul 2008 15:17:50 +0200, "$kymoi#" <§#q1$$@xxxx.fr> écrivait dans microsoft.public.fr.windows98:
Un fichier .bat intégré dans un fichier principal .bat ne rend pas la main au fichier principal (fichier lancé en premier) Pour être plus clair si dans le fichier que tu lances en premier, par exemple "toto1.bat" et que dans ce fichier tu intégres "toto2.bat", ce fichier "toto2.bat va s'exécuter mais ne rendra pas la main au fichier "toto1.bat". Si dans le fichier de lancement "toto1.bat" il y avait des instructions
C'est pour cela que j'ai inscrit
call u
et non
u
à exécuter après "toto2.bat , elle ne le seront pas. Depuis la version DOS 3.3, il existe une possibilité : Faire précéder chaque fichier .bat intégré dans un fichier principal de l'instruction CALL Exemple : call toto2.bat Une fois le contenu de ce fichier exécuté le système reviendra à la suite des instructions du fichier de départ "toto1.bat".
voir mon message...
call u toto call u toto2 call u toto3
u.bat change les noms des répertoires et cela marche bien si je fais des pause, par exemple :
cd c:%1 cd d:%1 call u2
mais le u2.bat qui contient la boucle plus haut marche dans environ 95% des cas.
et cela fonctionne dans 95% des cas et non 0%...
Denis
Le nombre de "files" ou "stacks" dans le contexte dos (config.sys) peut-être ?
Peut-être
Dans quel cas cela ne fonctionne pas (tes 5% restants) ?
Cela fait un bout que j'ai fait ce travail et je recommencerai dans plusieurs mois.
Ceci dit, je n'ai pas l'impression qu'il s'agit d'un problème de configuration car il y a des fichiers dont le nom est aussi long et qui passent sans difficulté. C'est peut-être lié au ~ des noms longs.
La prochaine fois, j'essaierai de réduire la longueur des noms pour voir si cela change quelque chose, et aussi de changer le config.sys. Je garde ce message comme non lu pour m'en rappeler !
Denis
Bonjour,
Je me souviens avoir posé en 2005 une question sur l'équivalent de la commande unix "wait" car j'avais des problèmes qui me semblaient liés au fait que certains ordres n'avaient pas le temps de s'éxécuter (un effet pervers du multi-tâche?). JC Bellamy m'avait à l'époque orienté vers le paramètre /wait dans mes fichiers.Bat (le texte exact ci-après).
[début]
Le but est de pouvoir lancer à la suite deux programmes suffisament incompatibles pour refuser de fonctionner ensemble.
Dans ce cas, il suffit de créer un simple batch, avec la commande START suivie du commutateur /WAIT !
@echo off start /wait appli1 start /wait appli2 ....
Avec "/wait", le passage à la ligne suivante n'a lieu que si l'appli ainsi lancée est terminée...
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
