Le fichier .cmd et le fichier .bat convertissant le code retour en un message d'erreur

Question

J'essaie d'automatiser un programme créé avec une suite de tests via un fichier .cmd.

Je peux obtenir le code de retour du programme que j'ai exécuté via% errorlevel%.

Mon programme a certains codes de retour pour chaque type d'erreur.

Par exemple:

1 - le moyen a échoué pour telle ou telle raison

2 - le moyen a échoué pour une autre raison

...

echo FAILED: le scénario de test a échoué, niveau d'erreur:% errorlevel% > > TestSuite1Log.txt

Au lieu de cela, j'aimerais dire:

echo FAILED: le scénario de test a échoué, raison de l'erreur: lookupError (% errorlevel%) > > TestSuite1Log.txt

Est-ce possible avec un fichier .bat? Ou dois-je passer à un langage de script tel que python / perl?

Answer 1

Vous pouvez le faire parfaitement avec l'option ENABLEDELAYEDEXPANSION . Cela vous permet d’utiliser ! en tant que marqueur de variable évalué après % .

REM Turn on Delayed Expansion
SETLOCAL ENABLEDELAYEDEXPANSION

REM Define messages as variables with the ERRORLEVEL on the end of the name
SET MESSAGE0=Everything is fine
SET MESSAGE1=Failed for such and such a reason
SET MESSAGE2=Failed for some other reason

REM Set ERRORLEVEL - or run command here
SET ERRORLEVEL=2

REM Print the message corresponding to the ERRORLEVEL
ECHO !MESSAGE%ERRORLEVEL%!

Tapez HELP SETLOCAL et HELP SET à l'invite de commande pour plus d'informations sur le développement différé.

Answer 2

Vous pouvez faire quelque chose comme le code suivant. Notez que les comparaisons de niveau d'erreur doivent être dans l'ordre décroissant en raison d'une anomalie cmd.

setlocal

rem Main script
call :LookupErrorReason %errorlevel%
echo FAILED Test case failed, error reason: %errorreason% >> TestSuite1Log.txt
goto :EndOfScript

rem Lookup subroutine
:LookupErrorReason
  if %%1 == 3 set errorreason=Some reason
  if %%1 == 2 set errorreason=Another reason
  if %%1 == 1 set errorreason=Third reason
goto :EndOfScript

:EndOfScript
endlocal

Answer 3

Pas exactement comme ça, avec un sous-programme, mais vous pouvez soit renseigner la variable a avec le texte à l'aide d'un voir solution de contournement.

Cela sera peut-être plus facile si votre suite de tests croît assez rapidement pour utiliser un langage plus puissant. Perl ou même Windows Scripting Host peuvent vous aider.

Answer 4

Oui, vous pouvez utiliser call. Juste sur une nouvelle ligne avoir un appel, et pas le code d'erreur. Cela devrait fonctionner, mais je n'ai pas encore testé.

C:\Users\matt.MATTLANT>help call
Calls one batch program from another.

CALL [drive:][path]filename [batch-parameters]

  batch-parameters   Specifies any command-line information required by the
                     batch program.

SEDIT: orry j’ai peut-être mal compris un peu, mais vous pouvez utiliser IF aussi

Answer 5

Testez vos valeurs dans l'ordre inverse et utilisez le comportement surchargé de SI :

.

@echo off
myApp.exe
if errorlevel 2 goto Do2
if errorlevel 1 goto do1
echo Success
goto End

:Do2
echo Something when 2 returned
goto End

:Do1
echo Something when 1 returned
goto End

:End

Si vous voulez être plus puissant, vous pouvez essayer quelque chose comme ceci (vous auriez besoin de remplacer% 1 par% errorlevel mais il est plus difficile de tester pour moi). Vous auriez besoin de mettre une étiquette pour chaque niveau d'erreur que vous traitez:

@echo off
echo passed %1
goto Label%1

:Label
echo not matched!
goto end

:Label1
echo One
goto end

:Label2
echo Two
goto end

:end

Voici un test:

C:\>test
passed
not matched!

C:\>test 9
passed 9
The system cannot find the batch label specified - Label9

C:\>test 1
passed 1
One

C:\>test 2
passed 2
Two

Answer 6

Vous pouvez utiliser l'instruction 'IF ERRORLEVEL' pour effectuer différentes opérations en fonction du code de retour.

Voir:

http://www.robvanderwoude.com/errorlevel.html

En réponse à votre deuxième question, je voudrais quand même utiliser un langage de script, car les fichiers de commandes Windows sont intrinsèquement très limités. Il existe d'excellentes distributions Windows pour Perl, Python, Ruby, etc., donc aucune raison de ne pas les utiliser, vraiment. Personnellement, j'adore les scripts Perl sous Windows.