We've never explicitly supported colors or animation or anything like that.

I recommend you file a bug against https://github.com/fatih/color and then let @fatih file a concrete bug here about what we changed, if anything. It might be a bug in the color package.

@bradfitz fatih/color#48

do you set color.NoColor = false ?

@mattn: Setting it explicitly in the test files fixes the issue.

// NoColor defines if the output is colorized or not. It's dynamically set to
// false or true based on the stdout's file descriptor referring to a terminal
// or not. This is a global option and affects all colors. For more control
// over each color block use the methods DisableColor() individually.
var NoColor = !isatty.IsTerminal(os.Stdout.Fd())

Seems like the problem lies here: https://github.com/mattn/go-isatty/blob/master/isatty_linux.go

Did Go start setting TERM=dumb this cycle? There was another bug about "go bug" reporting TERM=dumb.

go test handle output stream from testers. So NoColor should be true on tests.

Excuse me, I don't see how IsTerminal returning false on a terminal is considered correct behaviour.
There were no issues in 1.7.3.

Would you like me to file a bug report on https://github.com/mattn/go-isatty instead?

Please ask on golang-nuts.

It's likely because go test buffers the test output and thus
the direct output file descriptor is no longer a real tty device.

I've tested this with both go1.7.4 and go1.8.beta1. In 1.7.4 the file descriptor inside a test file is a terminal, however in go1.8beta1 it's no longer the case. This is the code piece I've used to test it:

package main

import (
	"fmt"
	"os"
	"testing"

	isatty "github.com/mattn/go-isatty"
)

func TestTerm(t *testing.T) {
	isTerminal := isatty.IsTerminal(os.Stdout.Fd())
	fmt.Printf("isTerminal = %+v\n", isTerminal)
	fmt.Printf("TERM=%q\n", os.Getenv("TERM"))
}

On 1.7.4 it's:

$ go test
isTerminal = true
TERM="xterm-256color"
PASS
ok  	_/Users/fatih/test	0.006s

on 1.8beta1 it's:

$ go test
isTerminal = false
TERM="xterm-256color"
PASS
ok  	_/Users/fatih/test	0.006s

I've also printed the TERM value to see if that changes somehow during the execution, which is not the case (it's printing my own custom value I've set)

I've checked https://beta.golang.org/doc/go1.8 but couldn't find any information about this change. I've tried to search for any changes about this in the codereview mail list and https://github.com/golang/go/blob/master/doc/go1.8.txt but there was no issues that might affect this. Can anyone point me if there is any information I can check why go test buffers or the respective change that triggers this?

@fatih,

Try your test with GOGC=off. When it works, the root cause probably may exist around careless system call invocation in the external package and the fix would be to call runtime.KeepAlive.

The same function, if executed inside a main package prints the following values:

On 1.7.4:

$ go run main.go
isTerminal = true
TERM="xterm-256color"

On 1.8beta1:

$ go run main.go
isTerminal = true
TERM="xterm-256color"

So it's only different when executed with go test

@mikioh I've set GOGC=off but it still prints false on 1.8beta1

@minux I think this should be a part of the release document or somehow documented. There might be projects outside that assumes stdout is a terminal. Thanks for the CL link, at least it makes sense now.

CL https://golang.org/cl/33857 mentions this issue.

We're going to revert part of the change so the test process's output is os.Stdout.

CL https://golang.org/cl/34010 mentions this issue.

CL https://golang.org/cl/35957 mentions this issue.

Change https://golang.org/cl/200106 mentions this issue: Revert "cmd/go: fail if a test binary exits with no output"

The decision taken here is making it hard to make certain improvements to go test, such as #29062. In #29062 (comment) I argue why I think we should undo this decision and consistently run tests without a real terminal. I might turn that into a proposal if needed.

My counter-argument above is now a proposal, in case anyone has thoughts: #34877