ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Burton" <bi...@progress.com>
Subject Re: <exec> task on NT/2000
Date Sun, 28 Jan 2001 01:10:08 GMT
Hello,

David.Bailey@lawson.com wrote:
> 
> Howdy.
> 
> We've moved from a makefile system (GNUmake on UNIX, NMAKE on Windows) to ant,
> and on the whole we're happy with it.  However, we have discovered an irritating
> feature of the <exec> task.
> 
> If I call
> 
>      <exec executable="perl">
>           <arg value="foo.pl" />
>      </exec>
> 
> then (I believe) ant passes "perl foo.pl" to the command line, and Windows knows
> what to do with it.  Even though I passed "perl" and not "perl.exe", it still
> launches foo.pl correctly.

Evidently perl.exe is in your path.  The automatic handling of .exe's
could quite possibly be built into the Windows CreateProcess function.

If you had the .pl suffix mapped to the path of your perl.exe so Windows
knows how to deal with .pl files when it gets the "Open" action, you could
probably run the script directly:
    <exec executable="foo.pl"/>

> I had hoped the same would be true for a .bat file, that is, that I could get
> ant to execute a file called "bar.bat" simply by invoking the following:
> 
>      <exec executable="bar" />
> 
> This appears not to be the case.  Even though typing "bar" at a command prompt
> works, my task in ant fails, because Windows doesn't know what I mean by "bar".
> Of course, "bar.bat" will work, but we are hoping to have a single build.xml
> work for all platforms as much as possible.  Using a call to "bar.bat" would
> require splitting my target into separate, platform-specific targets, or (worse
> yet) defining a ${BAR} property somewhere in a platform-specific way.

I was able to duplicate this behavior.  What this means of course is that
for some reason when a .bat suffix is specified, the appropriate Windows
shell (cmd.exe or command.com) is being invoked to execute the command. 
I've not seen any code in Ant that does this although I could have missed
it.  Possibly Runtime.exec or the Windows CreateProcess native function is
handling this.  In any case, the behavior isn't consistent when running
scripts from Ant.

If you're using a 1.1 or 1.2 JVM, you can get this to work (akwardly) by
specifying the "dir" attribute with a different directory.  This will
cause Ant to run your exec using either cmd.exe on NT/2K or antRun.bat on
Windows 9x/Me.  However, it appears you have to specify the slashes the
correct way for the executable attribute or it won't work.  For instance:
    <exec os="Windows" executable="bardir\bar" dir=".."/>
The above work around does not work when Ant is running under a 1.3 JVM
because Ant calls a new version of Runtime.exec that can switch the
default directory itself before launching the executable.

The other work around proposed by some of using a property for the script
suffix is probably best as it works with a 1.3 JVM and doesn't require and
unnecessary changing of directories.

The real solution it appears is to add a new "shell" attribute to the
<exec> and <execon> tasks.  The default would be "false" which gives the
current behavior.  When set to "true", Ant will force execution through
the antRun/.bat scripts or in the case of NT/2K use cmd.exe to execute the
command.  This logic is already there in Ant but just needs to be exposed
in the right way.

-Bill Burton

Mime
View raw message