Dog strips colors of task output

[victorb]

When using dog to run commands that prints out lines with colors, it seems like dog is stripping out the colors for some reason.

I have a project called Quickwiki that uses dog, and when running QUICKWIKI_DEBUG=1 go run main.go build ./wiki, it prints out colors.

But, when running QUICKWIKI_DEBUG=1 dog build-wiki, which runs the same command, the colors are stripped.

[xsb]

@victorbjelkholm sorry for replying so late. I can reproduce the error building your project but I can't reproduce it if I create a bash based dog task that prints text color escape sequences, in that case it works just fine.

I see you are using fatih's color package, I will try to reproduce it using it and hopefully fix it.

[ghost]

Most terminal coloring libraries (and probably fatih's, too) don't output escapes when their output is piped to something that is not a TTY; they usually rely on isatty(3) to detect this. This behaviour usually makes sense; you don't want to pass the coloring escapes to utilities such as grep.

[xsb]

@slapresta you are right, fatih/color package uses mattn/go-isatty to check if output needs to be colored or not. The behaviour is documented here.

// 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.
NoColor = !isatty.IsTerminal(os.Stdout.Fd()) || os.Getenv("TERM") == "dumb"

@victorbjelkholm I'm closing this issue.

[ghost]

Sorry, I didn't express myself clearly. I didn't mean that this wasn't an issue, I was just explaining what its cause could be. I believe that Dog should proxy this transparently; that is, the applications Dog invokes should transparently know if they're writing to a TTY.

The easiest way to do this is probably to pass os.Stdout as their Stdout when invoking them.