%q is by design.

Are you using windows?

Yes, I'm on Windows.

I was going to ignore this issue until I noticed kubectx/fzf.go uses %s, and the colors work.

As far as I know color printing on windows is fixed in master. Can you compile master and see if it works?

I did #220. 🙂 It works everywhere except this one place.

I went ahead and quoted %s so that it's consistent with the other places where %q is used, but the color still works. This was the only place where the %q verb was used with a colored argument.

fatih/color is no longer maintained, so I can't fix it upstream.

Ok let me take a closer look at this.
As the caller, we cannot possibly know not to use %q everywhere and we’ll keep making mistakes.

I agree. If you want to leave this open or create an issue to track it, I'll take another look when I get a chance.

Some ideas I had:

• Replace %q with \"%s\" in the printer
• Fork fatih/color, and fix it there

I went ahead an implemented the first idea. The %q works properly now. I also changed kubectx to use %q to so it's consistent with kubens.

I noticed while testing that the output for InteractiveSwitchOp differs from SwitchOp. Should we use color for both?

I noticed while testing that the output for InteractiveSwitchOp differs from SwitchOp. Should we use color for both?

This might’ve been an oversight, I don't recall tbh.

Regarding your current patch: Have you been able to figure out why is %q causing a problem with windows? As far as I know, setting the stdout/stderr to color.Output and color.Error should be fixing the problems.

As far as I can tell, the Windows behavior is actually correct. According to the fmt docs, %q should escape non-printable characters. The ESC character should be printed as "\x1b". If you want to output color, which starts with the ESC character, you shouldn't be using %q.

I wrote a sample without using any libraries.

package main

import "fmt"

const red = "\x1b[31mRed\x1b[0m"

func main() {
	fmt.Printf("%s\n", red)
	fmt.Printf("%q\n", red)
}

This produces the same output on Windows and in a Linux container.

According to the fmt docs, %q should escape non-printable characters.

🤔 if this was the case, I'd expect it to also do the same on mac/linux, but it isn't doing that.

What I was expecting was that the color package would render the color at the last minute (e.g. just before printing to the screen).

So I probably need to take a closer look at this, I’ll be busy for a bit, but hoping to get back to this PR soon, thanks for your effort.

Same happens to me in Linux, doesn't happen on Mac, using on both systems fzf.

Using kubens name works as intended.

@lopezator strange, for me it's not working on either Linux and Mac. kubectx prints the context in green while kubens shows the escape characters. Looking briefly at the docs I would agree with @jdharmon that this is the intended behavior of %s and %q.

I can also confirm that at least on Mac (with version 0.9.1) I see the escape characters with kubens but not with kubectx:

I can reproduce this problem in fzf 0.17.5, kubens 0.9.1, Debian 10. But kubectx is worked as expected.

Happens on macOS, iTerm (latest) and fish (latest) as well.

@ahmetb I replaced all occurrences of %q with "%s". Tested on Windows and WSL.

Can you restore the deleted files?

I just tripped over this, also on mac. Something to add:

$ kubens kube-system
✔ Active namespace is "kube-system"
$ kubens
✔ Active namespace is "\x1b[32mkube-public\x1b[0m".

The first invocation of "kubens" uses a parameter, prints fine.

The second invocation goes through fzf, selecting a namespace from the list. This one comes back with color codes printed as literal escape characters. I haven't been through the source to see why that might be, but it seems like it might help someone with better command of the code narrow this down faster to have better detail in the steps to reproduce.

@kingdonb this patch fixes both of them, I've built my fork with it to verify - https://github.com/caarlos0/kubectx

if you want to try: brew install caarlos0/tap/kubectx

also, @ahmetb my fork also have the needed changes to remove the bash stuff, I can open a PR with that if you want (mostly deletes and the goreleaser config).

@caarlos0 It looks like your main branch does several different things, I would suggest submitting each of them separately as a different PR, since some of that might not be merged.

I see your change translates %q to \"%s\" in a number of places, and I'm happy to review the source changes just as soon as I can figure out how to compile from your branch.

Matter of fact since you've done the work for me and I'm the one that thinks the commits should be reordered, let me copy your work and then go ahead and do that on my own, and I'll submit the PR. (Sec...)

I did not read the PR, sorry, I was confused...

Confirming this issue still exists in the master branch:

$ kubens
✔ Active namespace is "\x1b[32mcert-manager\x1b[0m".

binary is built from 9527e30 2020-11-14

With the changes @caarlos0 mentioned, in kingdonb/kubectx branch: testing, it indeed resolves the issue:

$ kubens
✔ Active namespace is "dash".

The "dash" is green text, which you can't see here, but it looks like those control characters are being interpreted correctly. My testing was done on MacOS in iterm2.

Submitting as PR #275

I see I just duplicated the work of this PR, sorry, closing 275

Sorry I didn't jump in earlier. This PR should fix the issue everyone's having.

@caarlos0 @kingdonb Can you confirm that this works correctly on Mac? I've tested on Windows and WSL.

I'm using it on macOS, works great 👍

Thanks!