Don't print colors when ANSI codes are not supported

[zoechi]

This is how the output looks like in WebStorm debug console:

debug:55618 --break-at-isolate-spawn --enable-vm-service:40572 --trace_service_pause_events /tmp/jetbrains_unit_config.dart
Testing started at 3:55 PM ...
Observatory listening on http://127.0.0.1:40572
00:00 �[32m+0�[0m�[31m -1�[0m: bwu_datastore_connection.test.model basic�[0m                                              
  type '() => Entity' is not a subtype of type 'Entity' of 'value'.
  dart:core         List.addAll
  model.dart 29:24  main.<fn>.<fn>
  dart:isolate      _RawReceivePortImpl._handleMessage

00:00 �[32m+0�[0m�[31m -1�[0m: �[31mSome tests failed.�[0m                                                                     

Process finished with exit code 0

Other packages run into this as well. pub itself is one of these where it works well.
see also

• http://dartbug.com/21337
• http://dartbug.com/15304

[nex3]

This is very difficult in full generality. The best way to detect this is to use stdioType, but that relies on having an accurate view of the process's IO streams. However, pub run spawns its executables as subprocesses and Dart doesn't provide any means of directly reassigning their IO streams to the parent process's IO streams, so they get an incorrect view. This in turn is blocked on several core library issues. So in general, this is blocked.

What we should do in the short term is support a --[no]-color flag. I've added the 0.12.0 milestone tag to track that.

[zoechi]

Why does it work in pub? When I run it in a shell which supports ANSI codes it's colored otherwise it's without color but also doesn't print the ANSI codes.

[nex3]

Pub isn't run inside pub 😉. It's possible for Dart programs to detect whether it's safe to use colors using stdioType; the problem is that this relies on having access to the real underlying stdio objects. When pub starts a subprocess, Dart doesn't provide any way of giving that process access to the parent's stdio, and thus the detection fails in the subprocess.

[zoechi]

I see. Thanks for the explanation!

[Fox32]

If I run my test file without the test runner from Dart Editor I would also not expect it to use ANSI codes (at least on Windows).

As this doesn't run via pub run, shouldn't it possible to use stdioType here?

[nex3]

@Fox32 There's no way of telling whether we're running via pub run or not. For now, the best solution is to just pass --no-color explicitly when color isn't desired.

[zoechi]

I haven't found a way to pass --no-color when the test is executed without the test runner. (dart test/my_test.dart

[nex3]

That's correct. Unfortunately, there's no global way to access command-line flags (issue 22466), so the test package can't use them when the script is run directly.

In general, you should think of running a script directly as a handy shortcut when working from the terminal. There are a lot of things it won't be able to support: not just colors, but configurations, annotations, and so forth. The official way to run a test is via pub run test, and that's how you should (for example) configure your editor to do so.

[zoechi]

This is inconvenient during development because this way debugging isn't supported. There is an open issue about debugging but I have no idea how this could work with pub run.

[nex3]

Issue 21791 will allow us to spin up test isolates with debugging ports open. For now, though, debugging is not officially supported; you're welcome to use it with dart path/to/script, but be aware that you're off the golden path at that point.

[zoechi]

Good to know

[Hixie]

You should be able to just look at the TERM environment variable to determine the current state of the console.

[nex3]

Accurately parsing TERM or TERMCAP is a lot of work, and it's easy for environment variables to flow into subprocesses and so forth and compromise the accuracy of that logic.

[Hixie]

It's the way e.g. ls works.

I don't see how anything else is going to work. How could e.g. a build script know to pass --no-color? Someone at some point is going to have to examine the terminal capabilities, since not everyone is going to be running the build scripts in the same environment. Asking everyone to write build scripts that check the terminal state to know whether to pass --no-color or not is a non-starter, IMHO.

[nex3]

As this comment mentions, the plan is to use stdioType to detect whether we're printing to a terminal or a pipe.

[grouma]

Closing: Working as intended.