-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix color in kubens success message when using fzf #228
Conversation
%q is by design. Are you using windows? |
Yes, I'm on Windows. I was going to ignore this issue until I noticed |
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 fatih/color is no longer maintained, so I can't fix it upstream. |
Ok let me take a closer look at this. |
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:
|
This might’ve been an oversight, I don't recall tbh. Regarding your current patch: Have you been able to figure out why is |
As far as I can tell, the Windows behavior is actually correct. According to the fmt docs, 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. |
🤔 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. |
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 |
Can you restore the deleted files? |
I just tripped over this, also on mac. Something to add:
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: |
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). |
I did not read the PR, sorry, I was confused... |
Confirming this issue still exists in the master branch:
binary is built from With the changes @caarlos0 mentioned, in
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.
I see I just duplicated the work of this PR, sorry, closing 275 |
I'm using it on macOS, works great 👍 |
Thanks! |
Kubens was displaying color codes when returning from fzf.