Suggestion noted. FYI, I was exposing the worse case. -----Original Message----- From: McCullough, Gary [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: RE: [Nant-users] No exit code from exe
Just a suggestion, but if you're running an exe hundreds of times per build, I'd be looking for a way to run it once per build. Of course, that's just theoretical, since I don't know whether it's possible, whether it's an in-house app or COTS, whether you can configure it, etc. But (if it was me) I'd sure try to find a way not to run an exe hundreds of times per build. ________________________________ Gary McCullough -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick, Brian E. Sent: Tuesday, August 03, 2004 9:37 AM To: [EMAIL PROTECTED] Subject: RE: [Nant-users] No exit code from exe Thanks Craig. That works for the most part, but I'm concerned about its robustness. The EXE will be run hundreds of times per build, in parallel, and its output can be large. Because of these characteristics, I would rather not have a file based solution. I modified your solution to overcome these issues, but I still have my reservations. I was hoping that someone would have a solution using a logger, filter, user task or some other memory based solution. If anyone has any ideas, I'm listening. Here is Craig's solution with my changes. <project name="ACME" default="external" > <property name="search_string" value="FATAL ERROR" /> <target name="external"> <property name="logfile" value="${path::get-temp-file-name()}"/> <exec program="cmd.exe" basedir="c:\windows\system32" commandline="/c dir" output="${logfile}" > </exec> <property name="stop.build" value="false"/> <foreach item="Line" property="log_line" in="${logfile}" > <do> <property name="stop.build" value="${string::contains(log_line, search_string)}" unless="${stop.build}" /> </do> </foreach> <delete file="${logfile}" failonerror="false" /> <fail message="Error found!" if="${stop.build}" /> </target> </project> -----Original Message----- From: Craig Green [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 9:19 PM To: [EMAIL PROTECTED] Subject: RE: [Nant-users] No exit code from exe Hi Brian, Your question inspired me to figure out how to do this. Here is what I learned. Disclaimer: I'm a complete nant newbie, so my way might not be the best way. You can log the output of your exec task and parse it with a foreach task. Below is an example build file that spawns an instance of cmd.exe that executes a dir command. If you want to test this as is, create a file called "FATAL ERROR". Otherwise you can try it out by replacing the exec task with your own. You could also put a regex task in the foreach loop to do some sophisticated pattern matching. Note: this build file will not work with nant versions prior to 0.85. <project name="ACME" default="external" > <property name="search_string" value="FATAL ERROR" /> <property name="logfile" value="dir.out" /> <target name="clean" > <delete file="${logfile}" failonerror="false" /> </target> <target name="external" depends="clean" > <exec program="cmd.exe" basedir="c:\windows\system32" commandline="/c dir" output="${logfile}" > </exec> <foreach item="Line" property="log_line" in="${logfile}" > <fail message="Error found!" if="${string::contains(log_line, search_string)}" /> </foreach> </target> </project> Good luck, -Craig Green -----Original Message----- From: Dick, Brian E. [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: [Nant-users] No exit code from exe I'm using the exec task to run an exe, but this particular exe does not set the exit code on success or failure. However, this exe does send a "FATAL ERROR" message to standard output if it fails. Is there a way I can monitor the output of this exe and set the exit code when "FATAL ERROR" occurs? Also, I still want to see the output in the build log, too. Later, BEDick ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
