Bug 36970 - Invalid return code in batch program
Summary: Invalid return code in batch program
Status: RESOLVED DUPLICATE of bug 13655
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.6.5
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: 1.7.0
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-07 19:38 UTC by Alan Hengle
Modified: 2008-02-22 12:18 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Hengle 2005-10-07 19:38:56 UTC
I am using a bat program to invoke ant after setting some environment variables;
then the following code to run and check the return code:
call ant
if errorlevel 1 (
	set /A failed += 1
	if "%ignore%" == "" goto bad
)

Even though the results of the ant build say "BUILD SUCCESSFUL" the errorlevel
returned is 1 and not 0.  If I use the -v parameter to ant ("call ant -v") it
returns the correct return code (0 on success, 1 on failure).
Comment 1 Steve Loughran 2005-10-10 11:48:28 UTC
Its not that Ant's return code is invalid, it is that Ant doesnt set one
indicating whether it succeeded or failed.

That has been a policy decision in the past, mainly for Win9x compatilbity. If
you can come with a patch for ant.bat that works on both the WinXP and Win9x
platforms, then we can fix it. 

Tip: the perl and python entry points do set the return value properly.
Comment 2 Dominique Devienne 2005-10-10 15:47:51 UTC
Steve, the same way we broke BC with Java 1.1, could we consider breaking BC 
for Win9x in ant.bat? I would think having a specific ant9x.bat script would be 
enough, no? I'd be +1 to have ant.bat properly propagate the 'correct' return 
code. --DD
Comment 3 Jose Alberto Fernandez 2005-10-10 16:12:00 UTC
If we want to write a script specific for WinNT, we could just call it ant.cmd 
which will work for NT (or is it XP) but not for 9x.

That will preserve BC and solve the issue. No?
Comment 4 Matt Benson 2005-10-10 16:34:45 UTC
(For example,) when I look at my XP config (on a new machine), %PATHEXT% is 
set to pick up .BAT -before- .CMD, so just placing an NT-specific ant.cmd file 
in $ANT_HOME/bin wouldn't (I predict) solve the issue.  I think one of my kids 
might still have a 9x version of one sort or another; if so I could try to do 
this... but after having had a look at the batch file I can say it won't be 
pretty.

-Matt
Comment 5 Matt Benson 2005-10-10 16:49:31 UTC
hmm... secondly, I imagine that the final solution need not work identically 
on both platforms; i.e.: the 9x result might not have all the behavior of the 
NT version, as long as the final batch file runs on both platforms... ;)
Comment 6 Steve Loughran 2005-10-11 11:23:29 UTC
If it were up to me, I'd abandon win9x support altogether. But I know the
eclipse and netbeans team try and support it, which is why the fact that
<property env> is broken still niggles me.

Maybe we could have the batch file do something different with error codes on
the two platforms. I have a win9x vmware image for testing...
Comment 7 Matt Benson 2005-10-11 16:46:46 UTC
All I know to do at this point is modify the batch file to do the right thing 
on NT, and dodge those commands on Win9x.  There are additional complications 
related to the structure of the batch file, but they are nothing major; pretty 
much the only detrimental effect will be ugliness.  The batch will still be 
crippled but functional on Win9x.
Comment 8 Antoine Levy-Lambert 2005-10-12 16:06:12 UTC
I agree with Matt. -:)
So we would document that ant.bat returns a significant return code on Windows
platforms other than Win9x.
Comment 9 Stefan Bodewig 2006-01-28 16:10:52 UTC

*** This bug has been marked as a duplicate of 13655 ***