
Signature
This signature intentionally left blank.
> It's got nothing to do with the OS or how "real" you perceive it be.
> It
> has to do with the fact that he is actually not executing in any
> shell.
> "copy" is a shell command, not a Windows executable.
The user shouldn't have to know that. If "copy" would work from the
command line where you ran "ant" it should work, whether it's a bat
file, a bash script under cygwin, a dos command.exe built-in, an alias,
an alternative "copy" early in the PATH environment, or whatever else is
appropriate in a given context.
Raymond DeCampo - 02 Apr 2006 04:00 GMT
>>It's got nothing to do with the OS or how "real" you perceive it be.
>>It
[quoted text clipped - 7 lines]
> an alternative "copy" early in the PATH environment, or whatever else is
> appropriate in a given context.
Whether or not you think it "should" work, the fact is it does not. One
should be familiar with the environment one is working in and understand
how to get things done. If you are using the <exec> task, you;ve tied
yourself to an OS and you'd better do it right for that OS.
Furthermore, the only reason such things appear to work in other
environments is that many versions of *nix include an executable for
things like "cp".
So your contention is that exec task for ANT should behave exactly the
same as the command interpreter for the shell that invoked it. There
are a few problems with that: first, the build script becomes dependent
on the shell; second, how does ANT determine which shell it was invoked
from; third, what do you do when ANT was not invoked from a shell at all
(e.g., from inside of an IDE). I'm sure there are more reasons this is
a bad idea, these are just the first ones that came to mind.
Ray

Signature
This signature intentionally left blank.