<div dir="ltr">Thanks, that makes sense. On a related note, currently, Swift sends version and runid to stdout and progress log to stderr, I think it would be better if everything Swift produces go to stderr and only user specified output go to stdout.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 5, 2014 at 8:47 PM, Hategan-Marandiuc, Philip M. <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Sat, 2014-04-05 at 19:59 -0500, Ketan Maheshwari wrote:<br>
> I agree this might not be needed in most cases. I was thinking of commands<br>
> or external programs that emit both stdout and stderr and say the list of<br>
> files that needs to be mapped are emitted only on one of the streams, in<br>
> such case user might want to ignore the other stream. Exitcode in this<br>
> context is a different issue.<br>
><br>
> For instance, user might have a Swift script that produce user written<br>
> trace() on stdout while progress log on stderr. In such case, this might be<br>
> useful:<br>
><br>
> file folder[ ] < array_mapper; files = system ("swift genfiles.swift", 1) >;<br>
<br>
</div>If we're trying to simulate shell commands, why re-invent the wheel and<br>
not use system("swift genfiles.swift 2>/dev/null")?<br>
<br>
<br>
</blockquote></div><br></div>