Return-Path: 
 <ant-dev-return-41750-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 58791 invoked from network); 27 Jan 2003 15:53:16 -0000
Received: from exchange.sun.com (192.18.33.10)
  by daedalus.apache.org with SMTP; 27 Jan 2003 15:53:16 -0000
Received: (qmail 27778 invoked by uid 97); 27 Jan 2003 15:54:40 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 27748 invoked by uid 97); 27 Jan 2003 15:54:39 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 27734 invoked by uid 50); 27 Jan 2003 15:54:38 -0000
Date: 27 Jan 2003 15:54:38 -0000
Message-ID: <20030127155438.27733.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: ant-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 16040]  -
    <exec>'s executable attribute is not converted to a full path on Solaris
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16040

<exec>'s executable attribute is not converted to a full path on Solaris





------- Additional Comments From ddevienne@lgc.com  2003-01-27 15:54 -------
I meant that currently, to resolve the exe name to a full path, you must 
attempt to find it against the system Path, by looking for it against each 
element of that path. This system path can be modified / changed by using a 
nested <env> tag so that the forked process executes under this new system 
path. Providing resolution against that updated path (rather than the system 
path of the Ant's JVM) would have solved an odd problem I was having in one of 
my build script on some machine, where

<exec executable="foo.exe">
  <env key="Path" path="C:/path/to/foo;${env.Path}" />
</exec>

would fail, even though foo.exe full pathname was C:/path/to/foo/foo.exe. 
Worked on other machines. Had to do 

<property name="foo.exe" location="foo.exe" />
<exec executable="${foo.exe}">
  <env key="Path" path="C:/path/to/foo;${env.Path}" />
</exec>

and override the foo.exe property in a user/machine-specific properties file to 
provide a full pathname to make it work on those troublesome machines (I still 
keep C:/path/to/foo on path of the forked process, since the latter was itself 
forking other stuff in there).

Anyhow, I think <exec> (and <java fork="true"> and <junit fork="true">) would 
benefit from supporting a special <path> or <syspath> nested element 
specifically for the purpose of setting the forked process system path (and the 
resolution of the executable name should use it if specified).

Am I making more sense? Thanks, --DD

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>