This works correctly if you don't use > out.txt and just run the program directly. This is because autoreset doesn't work when there is no tty (which is the case when using output redirection). The commit that added the tty check is here: https://code.google.com/p/colorama/source/detail?r=130c08c1fc5e8df1e3d6e5f97e2f9bf2391afc49&path=/colorama/ansitowin32.py
And this was in response to this issue: https://code.google.com/p/colorama/issues/detail?id=18
I actually don't think the issue in that link is correct -- I expect to see the red and the reset codes in the file just like you do. I think we need to remove this check and send the reset code regardless if there is a tty or not. @tartley what do you think?

When I forwarded this bug report, I hadn't realised that it was the redirection that was causing the autoreset codes to be omitted. Thanks for catching that @wiggin15!

The aim behind the fix for issue 18 was that Colorama should behave like standard unixy utilities such as 'ls' or 'grep', which only put ANSI color codes in their output if it is going to a terminal. If their stdout is redirected to a file, they do not use color (unless you add extra flags to force them to do so.)

If that is deemed to be desirable behaviour, then:

(a) the omission of the autoreset codes is working as intended, and
(b) perhaps some work needs to be done to make this behaviour more consistent (e.g. perhaps the initial '←[31m' codes should be stripped as well?)

On the other hand, I take your point that it might be simpler to handle this, if at all, at the application level, and colorama should just always print color codes when it is asked to. The downside of that is that lots of diverse applications would have to replicate these 'is_tty' checks (not a biggie really), but also that it's a break from the philosophy of the current behaviour, which I'd be nervous about given Colorama's surprisingly large install base.

Changing the implementation to always print the codes may be a break from the current philosophy, but not from the current behavior. If we fix this (autoreset), then colorama will continue to work as it does now, and will print colors in output redirections, so no applications will break.

btw, here's a quick look at others:

• termcolor (https://pypi.python.org/pypi/termcolor) also print the colors even if the output handle is not a tty
• logbook handle this (although they don't use colorama) in the application level: https://github.com/mitsuhiko/logbook/blob/00b3ba9c1eb92927c3260f7cc03f02cd5c0ed1d7/logbook/more.py#L297

lots of diverse applications would have to replicate these 'is_tty' checks

If we really want, we can add (yet another) flag to initialize, something like only_tty. If it's on, then in case there is no tty, we'll disable convert and enable wrap and strip. This will just be a small convenience for applications that decide they want that.

Fair enough then. I thought I'd applied this tty check with wider scope than that, but apparently not.

It gets deeper... Long explanation, sorry:

On Windows we also check is_a_tty, because colorama can't convert anything using the Win32 API if there is no console (that's a different reason than the one we discussed. When there is redirection on Windows we can't do conversion, whether we want to or not).
So, when running on Windows with redirection, 'convert' is 'False'. This means that in reset_all, we hit the 'else' clause that checks whether to print a reset code to the stream.
If we remove the is_a_tty check from there, then on Windows with redirection we'll actually print the RESET escape code, which is not desirable.

The proper fix should be to change:

elif not self.wrapped.closed and is_a_tty(self.wrapped):

to

elif not self.strip and not self.wrapped.closed:

Then, when autoreset is on:

• On Windows with tty, convert is True so we'll reset using the win32 call (same as before the change)
• On Windows without tty, convert is False and strip is True so we'll do nothing (same as before the change)
• On Linux with tty, convert is False and strip is False, so we'll print the reset code (same as before the change)
• On Linux without tty, same thing as above (fixes this issue)

In other words:

• On Windows, no reset codes are written in both cases
• On Linux, reset codes are written in both cases

Another note: if init is called on Linux with autoreset=True, strip=True, what should happen? The fix above disables the autoreset in this case, which makes sense because there will be nothing to reset - the escape codes are stripped.

I hope this wasn't too complicated. Am I making sense?

Lordy. Thank heavens someone has their wits about them. Yep, when I trace through what you wrote carefully, that makes perfect sense.

Linux autoreset=True, strip=True: My gut feel is that strip ought to trump autoreset, so nothing should be printed by the autoreset. My thought-experiment example use case for 'strip' is "my output device doesn't handle ansi codes, and I just want to avoid printing junk characters on the screen."

I pushed the commit to fix this.