Skip to content
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

Terminal colors of executable programs on Windows. #64

Closed
frederikhors opened this issue Dec 30, 2018 · 3 comments
Closed

Terminal colors of executable programs on Windows. #64

frederikhors opened this issue Dec 30, 2018 · 3 comments

Comments

@frederikhors
Copy link
Contributor

Dear people, modd is amazing!

I'm using:

  • Windows 10 and
  • powershell with
  • daemon: go run . in mood.conf,
  • with a simply standard golang app with chi router.

Any hint for show colors in terminal?

I can see all lines of the same color (white).

I already read:

but for Windows nothing.

How to do? Any hope?

@cortesi
Copy link
Owner

cortesi commented Dec 30, 2018

Hi there - I'm glad to hear you're fining modd useful. This really should be in the README, since it's such a common issue. The short summary is as follows:

The app that produces the console output detects whether it's connected to a TTY or not. If it is not, colour codes are not emitted. The only way for modd to "trick" client apps into thinking they are connected to a TTY would be to include full pseudo-TTY emulation, which is complex and hard to do cross-platform. I've decided that we can't go down that route. This leaves us with two remaining options:

  • Many (most?) systems that produce colour output also includes a way to force color codes, regardless of whether a TTY is present. You say you're using a Chi app, and I presume you want the log output from this to be colorized. Have a look at the docs for your logging library - for instance, logrus has a ForceColors flag you can set.
  • A final, last-ditch option is to interpose program that can emulate a TTY between the program you're running and modd. This is what unbuffer does. These tools are highly platform-specific, and sometimes not very reliable.

So there you have it - this is the complete rundown on colour output. I think your best option is to figure out how to force colour output in your app, and then to add a flag to control this to your daemon.

@cortesi
Copy link
Owner

cortesi commented Dec 30, 2018

I've just added an explanatory note to the README. Let me know if you feel that this needs any expansion or clarification.

@cortesi cortesi closed this as completed Dec 30, 2018
@frederikhors
Copy link
Contributor Author

@cortesi sorry for the (very) late reply.

I'm using modd a lot and is amazing. Thank you very much.

Today the problem with TTY and colours in my terminal has showed up again.

I read the README but I'm too stupid to fix it alone.

If in a project I'm using chi wich relies on https://github.com/go-chi/chi/blob/master/middleware/terminal.go:

func init() {
	// This is sort of cheating: if stdout is a character device, we assume
	// that means it's a TTY. Unfortunately, there are many non-TTY
	// character devices, but fortunately stdout is rarely set to any of
	// them.
	//
	// We could solve this properly by pulling in a dependency on
	// code.google.com/p/go.crypto/ssh/terminal, for instance, but as a
	// heuristic for whether to print in color or in black-and-white, I'd
	// really rather not.
	fi, err := os.Stdout.Stat()
	if err == nil {
		m := os.ModeDevice | os.ModeCharDevice
		isTTY = fi.Mode()&m == m
	}
}

I can fix it by forcing the isTTY to true somehow (and it works!).

After that I have a problem with another package which has a new logger middleware with new packages and so on.

I need a way to handle this for all packages and so I need to force TTY!

unbuffer is great but I'm not always on Linux and Windows sometimes shows up.

I think a tool like modd really need this internally.

Or at least we can find a way to force Windows somehow and we can update README.

I hope in your abilities and in your altruism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants