If by different you mean that they come out in a different order (but have the correct text otherwise), that is to be expected and what I meant above when I said:
The issue is basically that you are writing something to file A
and file B
, but there is a race condition involved in whether Sublime (or the terminal) read the data from A
first or B
first, if they happen to buffer the data a little bit before they write it out, and so on. This is what makes the whole operation non-deterministic.
As a simple example, there is this little snippet of python code:
import sys
for x in range(1,5):
print ("I am going to stdout", file=sys.stdout)
print ("I am going to stderr", file=sys.stderr)
This can provide all kinds of output, depending on what is (as far as we can discern) random chance.
The first time I run it in sublime I see:
I am going to stderr
I am going to stderr
I am going to stderr
I am going to stderr
I am going to stderr
I am going to stdout
I am going to stdout
I am going to stdout
I am going to stdout
I am going to stdout
This might make you think, “Oh, stderr
is displayed first!”, but then you run it again and see this:
I am going to stdout
I am going to stdout
I am going to stdout
I am going to stdout
I am going to stdout
I am going to stderr
I am going to stderr
I am going to stderr
I am going to stderr
I am going to stderr
Now they’re in the opposite order. What gives?
When I run it from the terminal, I see this:
tmartin:dart:~> python3 test.py
I am going to stdout
I am going to stderr
I am going to stdout
I am going to stderr
I am going to stdout
I am going to stderr
I am going to stdout
I am going to stderr
Now they’re interleaved like you might expect. You might fall into the trap of thinking that Sublime is at fault because it’s not providing the output that you expect to see and the terminal is, but in reality all three of them are doing the same things in a different order and it just so happens that one of those orders is the one that we hoped to see.
The effect here is subtle because the sample size is so small. If you increase the size of the loop to run 100’s of times, you start seeing chunks of first one line and then the other, and it’s possible that even in the terminal you see a couple doubled up.
To prove that it’s a race condition, try the same with the following sample:
import sys, time
for x in range(1,10):
print ("I am going to stdout", file=sys.stdout)
time.sleep (0.1)
print ("I am going to stderr", file=sys.stderr)
time.sleep (0.1)
Now everything interleaves like you would expect it to, because the sleep allows for (depending on your machine and other factors) plenty of time between each print statement for Sublime or the terminal to capture and display the lines as they’re generated.
If you imagine that instead of calls to sleep you have your own code in there, and how long each such call takes varies slightly depending on what the software happens to be doing at any particular point in time, you can see that sometimes things may be an issue and sometimes they may not.
The only way to fix a race condition properly is to remove the race by adding proper synchronization between the racing code paths to ensure that they operate at the appropriate time. The easiest way to do that would be to output all of the data to the same file.
As a fun aside, this sort of bug is often called a heisenbug because you might notice things going weirdly wrong, but when you add in logging to see what it’s doing, it works just fine (due to small delays spent logging). Or my particular favorite, it doesn’t work in the real world but when you run it in the debugger, the overhead of debugging slows everything down just enough to make it work.
Pretty sure this is why old programmers have beards; so they have something to tug at in frustration when things go wonky.