Bonjour,
 
Je dois, pour mon taf, créer du script en cmd, jusque là pas de soucis.
Ce script doit être éclaté en plusieurs sous-scripts pour faciliter les reprises en cas d'échec à une étape.
 
J'ai donc mon script maître, qu'on appellera le launcher, et les esclaves qu'on appellera 1/2/3.
 
Tout ce petit monde fonctionne parfaitement, excepté le retour au launcher.
 
J'ai créé une variable SaveType dans le launcher qui a pour valeur 1 ou 2 en fonction de si on est Lundi ou si on est Pas lundi. Cette variable et sa valeur passe parfaitement du launcher vers les sous-scripts.
 
J'ai créé une variable "codeFIN", initialisée à 0 (SET codeFIN=0 donc).
A la fin de chaque sous-script cette variable à nouveau SET avec une valeur =/= 0.
Mon soucis c'est que pour le launcher, cette variable vaut 0.
 
Qu'est-ce que j'ai raté?
 
En sachant que je n'utilise pas "setlocal" en début de script, sur aucun des scripts donc normalement mes variables ne sont pas cantonnées au script dans lequel elles sont déclarées...
A noter que mon launcher appelle les autres scripts via "START /WAIT "name" CMD /C mon_script.bat"

Pour le moment je suis sur un solution batarde où au lieu de modifier la variable, j'écris la valeur que je veux lui donner dans un fichier txt, et je récupère cette valeur dans le launcher via set /p codeFIN=<output.txt
 
Ca marche, mais c'est moche

Bonjour,
 
Le fait d'utiliser START crée une nouvelle instance cmd.exe qui peut hériter des variables du script appelant mais ces variables sont éliminées quand le script appelé se termine (source : https://ss64.com/nt/start.html).
La solution est donc de remplacer la commande START /WAIT par CALL
 
Au lieu de définir une variable codeFIN, tu pourrais utiliser la variable ERRORLEVEL (dans ton script maître) associé à la commande EXIT /B (dans tes scripts esclaves) qui définirait un code de sortie.

Bonjour,

en batch :
tu peux "linker" , lier les appels.
cela permet d'enchainer les appels de scripts et fonctions.

par exemple : pour remettre les fichiers systèmes en état :
sfc /Scannow & dism /online /cleanup-image /restorehealth :: 1 seul & est utilisé.
pourtant toute la ligne est dans le 'buffer'.

sfc /Scannow & dism /online /cleanup-image /restorehealth

1 seul & : toute la ligne est dans le buffer, mais la partie 'droite' est executée si et seulement si la partie gauche est réussie.

Quelle différence ?
1 seul & =>    command_1 et command_2 sont lancées , et executées.
 2 & =>  command_1 est excutée ; PUIS commande_2  

c'est utile pour chainer des appels.
et appliquer une contrainte.
"si 1 échoues , toute ligne échoues". [ effet de bord !!!! ]
"si 1 réussi , 2 est lancé"   =>  & [ c'est séquencé et dépendant de la réussite de chaque ]
"si 1 réussi , 2 est lancé" ou " 1 échoues , 2 est lancé " [ sans effet de bord, c'est séquencé et exclusif ] => &&  
" mes appels sont 'successifs' ( serial ) ; plutot que 'asynchrone' ( parallel ).
===========
pour gérer au mieux des 'trigger' pour un jour de la semaine :
il faut créer une task ...
par GUi dans le "task scheduler",
ou par une ligne de commande Batch.

pour ta question :
dans le cas ou tes taches peuvent être lancés indépendamment,
1 & fait un parfait travail.
si elles dépendent l'une de l'autre , et que la deuxième dépends de la première , tu les 'link' avec double & ( && ).

dans ton batch
si tu utilises start ... c'est 'asynchrone|parallel' ( & ) car plusieurs sessions console sont crées
si tu fais sans start ... c'est 'successif/serial' ( && ) dans la même session.

le setlocal, tu peux le laisser, il redéfinit des variables 'chemin' , des adresses disques durs, ( et des paramètres fenetres / typo / couleur /canal dédier / et les variables étendues ),
en fait à remettre setlocal dans ton script , tu 'reset/RAZ' temporairement l'environement console du Pc en question le temps de l'execution.

2 exemples :
====monBatch-1
commande_1   // succes ou échec
commande_2   // succes ou échec
commande_3   // succes ou échec
commande_4   // succes ou échec
=========
=========

c'est équivalent à :
====monBatch-2
commande_1 && commande_2 && commande_3 && commande_4
=========
========= c'est 'optimistic' // un échec n'est pas un gros problème. appel de commande suivant .....

  pas besoin d'utiliser 'start' .

si ton idée c'est d'ouvrir plusieurs fenetres 'console' ( plein plein plein de 'cmd' ):
start sera une syntaxe réduite.

start cmd /k dir /S *.*
start cmd /k tree
start cmd /k shutdown /r 60 //( secondes )

/k conserves la fenetre ouverte à la fin de l'execution
/u la refermes.

start cmd /k chkdsk /f /R && start cmd /k defrag c:
ou :
start cmd /k chkdsk /f /R & start cmd /k defrag c:   ( 1 seul & )