The exit/errorlevel logic seems weird, maybe there are some other environments that I am unaware of, but with 4NT and MKS the following issues appear: 1. Under MKS there is a color.exe command that does not properly return 0 when bg and fg colours are set. So if the build fails under MKS you black. :-) 2. Under 4NT the command "echo 1 > nul | choice /n /c:1" only applies the echo to the if the choice after the pipe gets executed. In the current logic, both of the following ifs will just return 1 rem Set the return code if we are not in NT. We can only set rem a value of 1, but it's better than nothing. if not "%OS%"=="Windows_NT" echo 1 > nul | choice /n /c:1 rem Set the ERRORLEVEL if we are running NT. if "%OS%"=="Windows_NT" color 00 I have rem'd out the two above ifs and replaced them with set ANT_ERROR=1 Then at the bottom of the script just do: exit /b %ANT_ERROR% I have done some testing: Consider the following ANT script (build.xml) fragment: <target name="pass"> <echo>Pass</echo> </target> <target name="fail"> <fail>Fail</fail> </target> and the batch file b.bat: > cat b.bat call ant %1 echo errorlevel = %errorlevel% the output under cmd.exe is: [w:\eas-6.1\dotnet\calc] [jagmain_delafran_vu] > cmd Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. [W:\eas-6.1\dotNet\calc] [jagmain_delafran_vu] > ver Microsoft Windows XP [Version 5.1.2600] [W:\eas-6.1\dotNet\calc] [jagmain_delafran_vu] > b pass [W:\eas-6.1\dotNet\calc] [jagmain_delafran_vu] > call ant pass Buildfile: build.xml pass: [echo] Pass BUILD SUCCESSFUL Total time: 0 seconds errorlevel = 0 [W:\eas-6.1\dotNet\calc] [jagmain_delafran_vu] > b fail [W:\eas-6.1\dotNet\calc] [jagmain_delafran_vu] > call ant fail Buildfile: build.xml fail: BUILD FAILED W:\eas-6.1\dotNet\calc\build.xml:33: Fail Total time: 0 seconds errorlevel = 1 [W:\eas-6.1\dotNet\calc] [jagmain_delafran_vu] > The output under 4NT.exe is: [w:\eas-6.1\dotnet\calc] [jagmain_delafran_vu] > ver 4NT 8.00.49 Windows XP [Version 5.1.2600] [w:\eas-6.1\dotnet\calc] [jagmain_delafran_vu] > b pass Buildfile: build.xml pass: [echo] Pass BUILD SUCCESSFUL Total time: 0 seconds errorlevel = 0 [w:\eas-6.1\dotnet\calc] [jagmain_delafran_vu] > b fail Buildfile: build.xml fail: BUILD FAILED W:\eas-6.1\dotNet\calc\build.xml:33: Fail Total time: 0 seconds errorlevel = 1 [w:\eas-6.1\dotnet\calc] [jagmain_delafran_vu] > So, the caller b.bat will properly get the return code (errorlevel) from the ant.bat file. I expect that any process the launches ant.bat will also get the proper return value.
Created attachment 19170 [details] patch generated from the SVN codeline
First, know that the .bat file is a source of much grief, much more than its short length would imply. We are scared of it. Historically the trouble has always been win98x support, as its batch language is much simpler. If you tried any of your patched scripts on win9x, things would break. Ant.7 doesnt support win98. so we may be able to change things, though as I said, we are scared of changes. There's no way we'd make the changes without going through a release cycle. Looking at the code, exit /b does look good; it sets the exit code and does not exit from nested batch files, which is probably exactly what everyone needs. The issue for the ant group is -do we adopt this (and so ensure no win98 compatibility) -what's our test process going to be.
What about the idea of two batch files: - antw98.bat (does the best job it can for windows 98 and possibly windows nt) - ant.bat (works best with Windows XP, 2000, 2003, Vista) and uses new script capabilities. Or use the same strategy and present a new ant.bat file: - ant2.bat (works best with Windows XP, 2000, 2003, Vista) and uses new script capabilities. - ant.bat (does the best job it can for windows 98 and possibly windows nt) ant.bat continues to keep the backward compatibility at its maximum. Existing build environments will continue to use the older script by default and will continue to function in its, much grief, state. ant2.bat could then be advertised as the new approach that takes advantage of better error reporting script features.
Hello Mark, going for antw98.bat and ant.bat sounds to me like the right choice. Regards, Antoine
I'm +1 for a separate 'legacy' win98 bat file, with a 'no support' clause. However, there is no way I'd release Ant with a new bat file without going through at least one beta cycle, so its too late to make the 1.7.0 cut. We can put this in Ant 1.7.1 though, and test it thoroughly before shipping to a wider audience. This could be a good time to clean up the .bat file altogether.
Why hasn't anything been done about this? Since ant.bat doesn't return an error code, my ant Python wrapper doesn't get when a build has failed (and I spent hours just identifying the cause). I've tested the attached patch on Windows Server 2008, Ant 1.8.1, and it fixes the issue.
Will try the patch. Antoine
I have used the patch and simplified it, removing the lines which were commented out. Also I have removed the line which said set ANT_ERROR=1 because I think this one would not have allowed to get different exit status. As I understand it, ant.bat will now provide an accurate exit status and not use these funny "color 00" and "echo 1 | choice" statements. Moving the status to fixed, hoping that it will not create other errors.