The ability to better-control the output of the exec task seems to be a common feature query...
I'm looking at putting together a patch for this, but would like to solicit comment on my proposed solution: Create an element type ExternalProgramOutput with three attributes - file (FileInfo), property (string) and log (bool). ExternalProgramBase will include two extra (non-attributed) public properties - stdout and stderr, both of type ExternalProgramOutput. For each of stdout and stderr, if the file attribute is specified then output will be logged to the specified file; if the property attribute is specified, then the output will be stored in the specified property; if log is true then output will be logged as normal, if false then output will be suppressed from the build log. Each of these attributes is orthogonal. If the stdout and stderr elements both specify the same file to log to, then output is (safely) interleaved into the log file - so the file contents will be essentially identical to running the command on the console and redirecting both stdout and stderr to a file, the only major difference being that stderr will not break into any stdout output. If either the stdout or stderr element is omitted, it will behave exactly as if the element were included with null attributes. That is, output will be included in the build log but not redirected or stored in a property. ExternalProgramBase's output attribute will be deprecated but still work as-is. Examples: <exec program="foo.exe"> <stdout file="out.txt" /> <stderr file="out.txt" /> </exec> * Exactly the same behaviour as the current <exec program="foo.exe" output="out.txt" /> <exec program="foo.exe"> <stdout file="out.txt" /> <stderr file="err.txt" /> </exec> * Redirect standard output and standard error to different files. <exec program="foo.exe"> <stdout property="foo" log="false" /> </exec> * Silently store the output of the program in the property 'foo'. Any errors will still appear in the build log. I'm not confident writing tests for this for any platform other than Win32, however - basically I don't know what standard commands might be available that emit a known text to stderr, and don't have access to a machine to run the tests. > >Comment By: Gert Driesen (drieseng) > Date: 2004-08-02 19:09 > > Message: > Logged In: YES > user_id=707851 > > I guess we should actually allow separate files for standard > and error output. > > Please submit a feature request or a patch for this. > > I'm closing this bug now as I'm not able to reproduce this issue. Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. ------------------------------------------------------- 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-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
