Toutes les autres réponses sont correctes: utilisez l'appel. Par exemple:
call "msbuild.bat"
Histoire
Dans les anciennes versions DOS, il n'était pas possible d'exécuter récursivement des fichiers batch. Ensuite, la commande d'appel a été introduite qui a appelé un autre shell cmd pour exécuter le fichier de commandes et renvoyé l'exécution au shell cmd appelant une fois terminé.
Évidemment, dans les versions ultérieures, aucun autre shell cmd n'était plus nécessaire.
Au début, de nombreux fichiers de commandes dépendaient du fait que l'appel d'un fichier de commandes ne reviendrait pas au fichier de commandes appelant. Changer ce comportement sans syntaxe supplémentaire aurait brisé de nombreux systèmes comme les systèmes de menus par lots (en utilisant des fichiers de commandes pour les structures de menus).
Comme dans de nombreux cas avec Microsoft, la compatibilité descendante est donc la raison de ce comportement.
Conseils
Si vos fichiers batch ont des espaces dans leurs noms, utilisez des guillemets autour du nom:
call "unit tests.bat"
Soit dit en passant: si vous n'avez pas tous les noms des fichiers de commandes, vous pouvez également utiliser for pour cela (cela ne garantit pas l'ordre correct des appels de fichiers de commandes; il suit l'ordre du système de fichiers):
FOR %x IN (*.bat) DO call "%x"
Vous pouvez également réagir sur les niveaux d'erreur après un appel. Utilisation:
exit /B 1 # Or any other integer value in 0..255
pour redonner un niveau d'erreur. 0 indique une exécution correcte. Dans le fichier batch appelant, vous pouvez réagir en utilisant
if errorlevel neq 0 <batch command>
À utiliser if errorlevel 1
si vous avez un Windows plus ancien que NT4 / 2000 / XP pour intercepter tous les niveaux d'erreur 1 et supérieurs.
Pour contrôler le flux d'un fichier batch, il y a goto :-(
if errorlevel 2 goto label2
if errorlevel 1 goto label1
...
:label1
...
:label2
...
Comme d'autres l'ont souligné: jetez un œil aux systèmes de construction pour remplacer les fichiers batch.