-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isatty
causing false negatives
#7
Comments
Excuse me, I'm NOT going to add any flag to richgo. |
Totally understand, I tried to mention that in my original report but may
not have expressed it properly.
Thanks for your project btw, I've really been enjoying it and am trying to
integrate it into all the projects i work on :)
…On Fri, Feb 3, 2017 at 2:19 AM Kyoichiro Yamada ***@***.***> wrote:
Sorry, I'm NOT going to add any flag to richgo.
Please use env-vars alternatively.
ex. RICHGO_FORCE=1 richgo test ./...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAF7P6IvR6ydqZsXIWRO7o-Lz6NorQfaks5rYrw9gaJpZM4L1FHa>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Working on integration with some other tools, I've noticed that richgo uses
isatty
to determine whether or not to try to colorize the output. I remember having a similar conversations with the authors ofglide
. The problem in my case is that I'm piping some commands together, so stdout isn't connected to a TTY according to theisatty
library, but it's certainly capable of displaying color.Here is their discussion: Masterminds/glide#358
Turns out the problem isn't that simple. However, a workaround is: add a flag to richgo to try color even if it's not connected to a tty.
In other words, If I run
richgo test --color ./...
then try to colorize regardless of the TTY-ness of the output device.I realize that complicates things since most of the command line arguments are currently passed through as-is to
go
. Perhaps we should make this an environment variable then?If you're willing to accept one of the above options, I'd be happy to code it up, otherwise I'll go ahead and make a small fork since it seems we'd like to use the tool for different things.
The text was updated successfully, but these errors were encountered: