Color codes output to non-ttys

[larkost]

Like the writer of #1296 I am piping the output of Mocha tests to a non-tty (file in this case), and am getting control characters (specifically those for colors) in my text. This is nasty as I am trying to support unicode characters, and that makes life difficult.

The reports code appears correct, but I tracked the problem down to a combination of two places in lib/mocha.js:

1. in Mocha.prototype.useColors the default if there is no setting is to be true, if you have selected neither -c/--colors or -C/--no-colors this gets called called by mocha.js with undefined in the line this.useColors(options.useColors), so this.options.useColors is true.
2. In Mocha.prototype.run there is the line:

exports.reporters.Base.useColors = options.useColors;

Since this does not get run until the Mocha object is instantiated, it is run later than the code in the top-level of the the reports modules. So this one always overrides what is set in reporters modules, and always sets it to true, unless you explicitly call -C/--no-colors.

A correction would be to change that last line to:

if (exports.reporters.Base.useColors == undefined) exports.reporters.Base.useColors = options.useColors;

[boneskull]

resolved by 3997ad0

[larkost]

3997ad0 does not solve this issue. That ONLY solves the case when you have specified --no-colors. It does NOT solve the automatic case when STDERR or STDOUT is not a tty. Please re-open this issue.

edit: Forgot to mention that I had already tested that as a solution.

[boneskull]

I understand. This may be a better solution however:

this.useColors(options.useColors === undefined ? process.stdout.isTTY : options.useColors);

[larkost]

That is a valid choice, and would work for my situation. However you solve it, please make sure to rationalize it across all of the files that try to set it:

• lib/mocha.js
• lib/reporters/base.js
• mocha.js

Your proposed solution would make the existing code elsewhere not only meaningless (as it is at the moment), but also misleading.

Oh.. and as is done in lib/reporters/base.js colors should probably only be defaulted on if both STDOUT and STDERR are tty's.

[mcandre]

@larkost +1

[larkost]

In a perfect solution, not only should be they be tty's, but ones where the termcp entries for at least red and green exist. There are a bunch of odd corners that you can run into: emacs eshell is one of them (not that I a fan).

[boneskull]

@larkost Feel free to send PR if you have time

[Bogidon]

Eh probably not the best place to post this, but I made a very much hacky port of the Spec reporter that uses browser console.log CSS features to make debugging Mocha with browser dev tools more delightful. For a more robust solution, Base could probably be extended relatively straightforwardly to deal with multiple color "escape code" formats.

Here it is: https://gist.github.com/Bogidon/d088c94596d910dc755660365fda4d97

[dskrvk]

Still happening to me in 3.3.0. Reproduces with mocha server/test/* > test.out -> the file contains control characters.

[stale]

I am a bot that watches issues for inactivity.
This issue hasn't had any recent activity, and I'm labeling it stale. In 14 days, if there are no further comments or activity, I will close this issue.
Thanks for contributing to Mocha!

[larkost]

This bot seems like a bad idea. This is a legitimate issue, and it is very unlikely that it has been fixed. Just paving over "stale" issues like this is not advancing the project, only making someone's numbers look good.