Open izelnakri opened 6 years ago
I'm currently using https://github.com/garabik/grc for lots of cli tools I use, including kubectl
, another alternative, probably more performant could be to use pipecolor
but you need to set up the pattern matching https://github.com/dalance/pipecolor/issues/2
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
/remove-lifecycle rotten
when this feature is coming?
Any updates?
Now that kubecolor is archived, I believe this is more important than ever. :)
I agree completely with @felipecrs that we need to add support to this, this also helps people who have special eyes 👀 , this will increase the accessibility to kubectl.
workaround so far: https://github.com/itaysk/kubectl-neat
alias in my .zshrc
file:
alias kneat="kubectl neat | yq"
Then i pipe my get commands to kneat
.
kubectl get nodes -l gitlab=true -o yaml | kneat
workaround so far: https://github.com/itaysk/kubectl-neat
alias in my
.zshrc
file:alias kneat="kubectl neat | yq"
Then i pipe my get commands to
kneat
.
kubectl get nodes -l gitlab=true -o yaml | kneat
Gold, thanks for sharing.
This feature should be built-in. but in any case, is a good hack, thanks @WladyX
Best Regards, H
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Sharing trick based on @spuder comment earlier but using bat: A cat(1) clone with wings. https://github.com/sharkdp/bat
kubectl get $type $name -oyaml | cat -l yaml --paging=never
Alias
function vml() {
cat -l yaml --paging=never
}
kubectl get $type $name -oyaml | vml
Output
PS: this is using gruvbox-dark theme from bat.
Also please note that here bat
is aliased to cat
alias cat='bat --paging=never'
from the bat docs.
Just FYI I've made a CLI tool to do this. https://github.com/dty1er/kubecolor
For reference, here's the new maintained one: https://github.com/kubecolor/kubecolor
Maybe the answer we are looking for here is the ability to locally remap kubectl commands. Consider:
kubecolor
) to do the same thingsThe ability to generically override commands as a part of the login context would cover these bases. A service account with no overrides would get raw output, users who had customizations would get their preferred output format without having to use a different command set.
A final tweak on this would be to allow krew to update the override config. So if someone installed kubecolor
, existing commands would be automatically remapped upon installation without magic.
Honestly, I think that's overengineering. kubectl itself could output colors based on whether it is running in a terminal with color support or not. Like bat itself, which automatically disables color when being executed in things like pipes.
kubectl itself could output colors based on whether it is running in a terminal with color support or not
Point taken, but one may want a completely different output for the same basic commands.
side wish, kinda wished that kubectl describe allowed output format, so that it can be piped to a any syntax highlighter
On Thu, Apr 18, 2024 at 1:33 PM Brian Topping @.***> wrote:
kubectl itself could output colors based on whether it is running in a terminal with color support or not
Point taken, but one may want a completely different output for the same basic commands.
— Reply to this email directly, view it on GitHub https://github.com/kubernetes/kubectl/issues/524#issuecomment-2065269011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET32OXYPVUKJ7RW2I3A3HLY6AUZDAVCNFSM4FRPBD42U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWGUZDMOJQGEYQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
FEATURE REQUEST:
Currently kubectl outputs are pretty boring without a color:
Adding color to them will make them easier to read. Each key could be colored based on its indentation level. Each key/value pair in labels,annotations,taints etc could be colored differently as well.