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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
