The generic constructor accepts any os.File pointer. This is useful when this library is used to support a generic colorable writer stream whose destination (stdout, stderr, log file, etc.) is determined dynamically at runtime.

Old constructors are kept for backwards compatibility.

Will conflict with #10

There is a subtle problem with cross-compilation for windows under linux/darwin.

1. go get github.com/mattn/go-colorable being run under linux/darwin skips dependencies in file colorable_windows.go, because of "_windows" prefix. This file though has one external dependency - 'github.com/mattn/isatty', which is ignored and isn't downloaded during go get.
2. If user want to cross-compile package for windows, go build will return error as it has missing dependency: $ GOOS=windows go build github.com/mattn/go-colorable colorable_windows.go:13:2: cannot find package "github.com/mattn/go-isatty" in any of: /usr/local/go/src/github.com/mattn/go-isatty (from $GOROOT) /Users/divan/src/github.com/mattn/go-isatty (from $GOPATH)
3. Being a general purpose library, it's imported from many more projects, gin-gonic among them. It ends with users confusion, when he tries to cross-compile package, which depends on go-colorable and it takes time to figure out this issue.

My proposal is to import 'github.com/mattn/isatty' into colorable_others.go as well to allow go get resolve it as dependency regardless of which platform is used. + _ "github.com/mattn/go-isatty"

Echo, a web framework for go uses go-colorable (To be exact, gommon depended by Echo uses go-colorable).

When developing an application for Go on Google AppEngine with Echo and testing it on Windows, it causes following build failure:

> goapp serve
...
2017/03/12 10:49:49 go-app-builder: Failed parsing input: parser: bad import "syscall" in github.com\mattn\go-colorable\colorable_others.go from GOPATH

This is caused as Go on Google AppEngine restricts importing syscall.

This change make go-colorable use colorable_others.go also on Windows when built with appengine.

This ticket originates in research done for epinio/epinio/issues/673, itself a follow up of epinio/epinio/issues/494

The relevant setup is

• Platform: Win 10 Home (Virtual Machine, Linux-hosted, VirtualBox)
• Modules (grep 'fatih\|mattn' go.mod):
  • github.com/fatih/color v1.12.0
  • github.com/mattn/go-isatty v0.0.12
• Sum Modules (grep 'fatih\|mattn' go.sum |grep -v go.mod):
  • github.com/fatih/color v1.12.0 h1:mRhaKNwANqRgUBGKmnI5ZxEk7QXmjQeCcuYFMX2bfcc=
  • github.com/mattn/go-colorable v0.1.8 h1:c1ghPdyEDarC70ftn0y+A/Ee++9zz8ljHG1b13eJ0s8=
  • github.com/mattn/go-isatty v0.0.12 h1:wuysRhFDzyxgEmMf5xjvJ2M9dZoWAXNNr5LSBS7uHXY=
  • github.com/mattn/go-runewidth v0.0.7 h1:Ei8KR0497xHyKJPAv59M1dkC+rOZCMBJ+t3fZ+twI54= Without excluding go.mod lines I see a lot more versions for all the packages.

Below a screenshot demonstrating the differences between a mingw bash (from git for windows) on one side, and cmd.exe and PowerShell on the other side:

While I originally thought that maybe the IsTerminal generates an incorrect result, disabling handling with the output from my last tests I now have to suspect an issue either here in go-colorable, or in its user, https://github.com/fatih/color, which is the actual package used by the epinio code. And I do not see how our use of the fatih/color would be incorrect.

With regard to the version numbers, fatih/color is at 1.12.0, the latest release as of May 24 this year. Which in turn uses the latest tag 0.1.8 for go-colorable, as of Oct 3 last year.

Any ideas where else to look for the issue ?

I've used Kubebuilder to generate a bunch of code for a Kubernetes custom resource controller. I'd like my custom resource controller to manage BOSH releases so I've got code similar to this to construct a BOSH Director client to pass to my reconciliation controller so it can use it to manage BOSH releases. After adding this code to some of the Kubebuilder-generated code, and running make generate from the Kubebuilder-generated Makefile, it fails when I run go fmt ./....

$ go fmt ./...
go: downloading gopkg.in/mattn/go-colorable.v0 v0.1.2
go: downloading gopkg.in/mattn/go-isatty.v0 v0.0.8
build github.com/amitkgupta/boshv3: cannot load gopkg.in/mattn/go-colorable.v0: cannot find module providing package gopkg.in/mattn/go-colorable.v0

I'm not importing go-colorable directly anywhere in my code, my guess is some of the packages from github.com/cloudfoundry/bosh-cli that I'm importing have some recursive dependency on go-colorable, so I don't think I can solve this by modifying any import paths in my own code.

Any pointers on how I might troubleshoot this? I saw #35 but none of the ideas there seemed to help.

Before

After

Description

csbi.window.top seems to become 1 or higher when scrolling down. csbi.window.top seems the number of hidden lines at the top. But FillConsoleOutputCharacterW()'s dwWriteCoord is a coordinate of terminal, not lines and cols. NOTE: I could not test when csbi.window.left is 1 or higher.

Beside ANSI codes <esc>[s (save cursor position) and <esc>[u (restore cursor position) there are also widely used DEC code: <esc>7 and <esc>8 which do mostly the same, but are preferred sometimes because <esc>[s and <esc>[u don't work in some terminals like VT100 and Mosh (See https://github.com/mobile-shell/mosh/issues/726)

See also: "Some terminals require the DEC sequences ESC 7 / ESC 8 instead which is more widely supported." See https://en.wikipedia.org/wiki/ANSI_escape_code#Examples

See also: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#span-idsimplecursorpositioningspanspan-idsimplecursorpositioningspanspan-idsimplecursorpositioningspansimple-cursor-positioning

https://vt100.net/docs/vt100-ug/chapter3.html#DECSC

Can you add such an alias?

I used to access https://github.com/mattn/go-colorable/archive/d228849504861217f796da67fae4f6e347643f15/go-colorable-d228849.tar.gz directly, but mow getting "curl: (22) The requested URL returned error: 500 Internal Server Error" do you know whether this should still work?

On func (w *Writer) Write([]byte) of colorable_windows.go, procGetConsoleScreenBufferInfo is called twice and the resuilt of the first one looks to be unused.

It does not cause any problems, but by removing one api-call, the speed to draw text may be improved.

ANSI sequences are defined in the ASCII encoding. Any stream of bytes in an encoding which is a superset of ASCII should be processable through a colorable and any byte that is not part of an ANSI sequence should kept as is.

go-colorable does not fit this because it uses ReadRune. This gives the following issues:

• a non-UTF-8 stream will be transformed into an UTF-8 stream with non-UTF8 bytes replaced by U+FFFD
• even an UTF-8 stream may be altered if the stream is fed through the colorable using Write calls that are not on rune boundaries

This patch adds tests checking encoding agnosticness, and shows that NonColorable fails as transmitting Latin-1. I can go further improving this testuite to include Colorable and provide fixes once this issue is recognized as a flaw that must be fixed.

Hi. I'm using go-colorable indirectly via a chain of dependencies. Following the instructions of godep - https://github.com/tools/godep/issues/131 - I declared and added the godep workspace vendorized to the project with godep save.

Added power support for the travis.yml file with ppc64le. This is part of the Ubuntu distribution for ppc64le. This helps us simplify testing later when distributions are re-building and re-releasing. For more info tag @gerrith3.

When using from an ssh session using vagrant into a windows, then it crashes with in "colorable_windows.go" line 507

https://github.com/mattn/go-colorable/blob/master/colorable_windows.go#L507

It does not happen all the time but feels uncomfortable to have this in prod. Steps:

1. be on linux
2. open terminal and vagrant ssh windows
3. do some high intensive outputs , like animation with colors, I use the spinner as you can see from screenshots

Something clashes there

When trying to go get go-colorable from gopkg, I'm currently getting this message (using Go 1.12):

go get -u gopkg.in/mattn/go-colorable.v0
go: gopkg.in/mattn/[email protected]: go.mod has non-....v0 module path "github.com/mattn/go-colorable" at revision v0.1.1
go get: error loading module requirements

It seems to me like there is some kind of conflict between the gopkg.in/mattn/go-colorable.v0 actual package path and the name of the module declared in the go.mod file github.com/mattn/go-colorable.

For now, forcing the use of the lib without the go.mod file in it solves the issue:

go get -u gopkg.in/mattn/[email protected]
go: finding gopkg.in/mattn/go-colorable.v0 v0.1.0
go: downloading gopkg.in/mattn/go-colorable.v0 v0.1.0
go: extracting gopkg.in/mattn/go-colorable.v0 v0.1.0

Hey Mattn, I like this workaround for Windows. Instead of documenting it as a workaround in the README, could we use this smartly upstream without downloading the library for all platforms?

I want to use Sourcegraph for go-colorable code search, browsing, and usage examples. Can an admin enable Sourcegraph for this repository? Just go to https://sourcegraph.com/github.com/mattn/go-colorable. (It should only take 30 seconds.)

Thank you!