Re: System.out and System.err
Andreas Leitgeb wrote:
Jan Thom?? <janthomae@janthomae.de> wrote:
On 2008-10-02 11:56:33 +0200, Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> said:
If (e.g. on unix) you start some java-application like this:
java MyApp > /tmp/MyAppLog 2> /tmp/MyAppLog
(with ">", not ">>" !)
I could imagine that they might still overwrite each other, despite
being thread-safe each on its own.
Well but this is something completely out of the control of the
program.
Indeed it is. Let's recall Mike's words:
... the worst that will happen is output getting interleaved
but not lost, ...
The output from the program isn't getting lost. It is getting lost *after* it
has left the program. You could just as easily redirect one of the channels to
the /dev/null bit-bucket and claim that demonstrated the output could get lost.
Now, depending on external conditions, the application itself
may overwrite its previous output to System.err by outputting
to System.out and/or vice versa.
You have not demonstrated that the program is overwriting its own output. That
is being done by shell redirection.
Output *can* get lost, while the application is still running,
and *without* anyone *else* removing or truncating the file at
the same time.
But someone else *is* doing it, the shell. The application is not even writing
to a file...
class Test {
public static void main(String[] args)
{
System.out.print("@");
for (char ch='a'; ch <= 'z';) {
System.err.print(""+ch+ch); ch++;
System.out.print(""+ch+ch); ch++;
}
}
}
// I was too lazy to look at the javadocs for String on how
// better to create a string of instances of a given char.
Let it run on console and you see each char twice, ditto
when redirecting >bar 2>&1, but if you redirect both
individually to the same file, then each but the z will
appear only once.
Blaming the program for this would be like blaming it for not
being able to write on a defective disc...
I didn't *blame* anyone or anything for anything.
But you ascribed the problem to the application, when the fault lies in shell
mis/redirection.
--
Nigel Wade