Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B0945BD.B8F07C53@digitalfocus.com>
Date: Mon, 21 May 2001 12:43:41 -0400
From: Daniel Barclay <Daniel DOT Barclay AT digitalfocus DOT com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ant-user AT jakarta DOT apache DOT org" <ant-user AT jakarta DOT apache DOT org>,
        cygwin <cygwin AT cygwin DOT com>
Subject: help - Ant execution search path / Cygwin interaction
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can anyone help me understand how Ant and Cygwin interact?

Does Ant's exec task somehow ignore or reset the execution search path
instead of using the value of the PATH environment variable inherited 
from the process that ran Ant?


When I run Ant from CygWin bash, Ant seems to be ignoring or resetting 
the execution search path.

Specifically, when I try to run the GNU find command using an exec task, 
it runs the DOS find command instead.  It seems to ignore my PATH variable.

My PATH variable in bash lists the CygWin directories first:

  $ printenv PATH
 
/c/tools/emacs-20.7/bin:/usr/bin:/usr/bin:/c/WINNT/system32:/c/WINNT:/c/PROGRA~1/Tcl/bin:/c/Daniel/bin:/c/tools/ant-1.3/bin:/c/tools/jdk1.3/bin:/c/tools/j2sdkee1.3/bin:/c/WINNT/system32:/c/WINNT:/c/PROGRA~1/Tcl/bin

Bash correctly finds the GNU version when I run "find":

  $ find -version
  GNU find version 4.1
  $ 

When I run "printenv PATH" using ant Ant "exec" task, it shows that the
process run by Ant has inherited the correct value of the PATH environment
variable (it has found Cygwin's printenv executable, and printenv prints
a search path with /usr/bin before WINNT directories):

     ...
     [exec] The command attribute is deprecated. Please use the executable attribute and nested arg
elements.
     [exec] Myos = Windows NT
     [exec] printenv PATH
     [exec]
/c/tools/emacs-20.7/bin:/c/tools/emacs-20.7/bin:/usr/local/bin:/usr/bin:/usr/bin:/c/WINNT/system32:/c/WINNT:/c/PROGRA~1/Tcl/bin:/c/Daniel/bin:/c/tools/ant-1.3/bin:/c/tools/jdk1.3/bin:/c/tools/j2sdkee1.3/bin:/c/WINNT/system32:/c/WINNT:/c/PROGRA~1/Tcl/bin
     ...

However, when I run "find" using an exec task, it's obvious that Ant runs
the DOS version:

     ...
     [exec] The command attribute is deprecated. Please use the executable attribute and nested arg
elements.
     [exec] Myos = Windows NT
     [exec] find -version
     [exec] FIND: Parameter format not correct
     [exec] Result: 2
     ...

So if Ant inherits the correct variable of PATH, as evidenced above, why 
doesn't Ant find the Cygwin version of find instead of the DOS version?


Cygwin environment variables seem to propagate into spawned DOS shell just
fine (starting in bash, runnning "export x=y", "cmd", "set x" shows "x=y").

The Cygwin PATH variable seems to propagate fine (starting in bash, "cmd", 
"find -version" runs GNU find).

Does Ant (e.g., Java) somehow reset the environment to Windows/DOS defaults
when it starts an executable?  Does it do anything else that might cause
this behavior?


Thanks,
Daniel
-- 
Daniel Barclay
Digital Focus
Daniel DOT Barclay AT digitalfocus DOT com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple