Open brunopereira7 opened 1 year ago
xbar is not using your regular user's environment, define your PATH
to include everything you need, including the initialisations you are running via your .bashrc
or .zshrc
etc.
If it is only about PATH
then you can simply use absolute paths instead of relative ones.
For example, if you are lazy/careless you can put source ~/.zshrc
at the top of your script BUT that can slow down your script significantly depending on how much work you are doing in your ~/.zshrc
.
@brunopereira7 PR https://github.com/matryer/xbar-plugins/pull/2035 will probably fix your issue.
https://github.com/matryer/xbar-plugins/pull/2035 has been merged @brunopereira7 please test and confirm.
Hi @Raboo, thanks for your work, but unfortunately, it still does not fix my issue. Just to wrap up, now I have the following scenarios:
Scenario 1: Working as expected when xbar is launched via terminal (open -a xbar.app
):
Scenario 2: xbar is launched via applications or started at login. I can't switch the context and namespace.
The last status is that the context list is okay, but I can't switch the context. The current namespace is greyed out, and I don't have the namespace list, so I can't switch.
Btw, I was trying to find a way to debug the Xbar app and to understand what could be causing this behavior, but I am still looking for a way. Feel free to share any insights/ideas :)
Thanks again for your work!
Ok I am able to replicate the problem with multiple kubeconfigs and not being able to switch context..
Strange thing if I run the command manually (kubectl config use-context $NAMESPACE
) it works and that is what xbar should do when you click on a context name. Not really understanding why it's not switching the context.
Ok, I've figured it out the problem on my machine, YMMV. Problem for me was that I had multiple clusters with the same name.
contexts:
- context:
cluster: local
user: user
namespace: kube-system
name: Something
So even if the context is called "Something". The Something context uses a cluster called local. And when I have multiple clusters with the name local, I cannot switch to it using xbar and I cannot list its namespaces if it is selected from outside of xbar.
@brunopereira7 can you verify that you don't have multiple clusters with the same name across your kubeconfig files?
Hi @Raboo , I've double-checked and confirmed that my clusters have different names across the kubeconfig files.
echo $KUBECONFIG
/Users/miguebru/.kube/docker-desktop.kubecfg:/Users/miguebru/.kube/sandbox.kubecfg:/Users/miguebru/.kube/dlc-nonprod.kubecfg:/Users/miguebru/.kube/dlc-prod.kubecfg
The weirdest thing is if I launch xbar via command line open -a xbar.app
everything works as expected 😕
I can only assume when you run open -a xbar.app
from a terminal it has all the environment variables that you have in your shell.
So perhaps it is some other environment variable that your setup needs.
If you run
unset $(env | cut -d= -f1 | egrep -v "PATH")
open -a xbar.app
Will it still work?
If not perhaps you can one by one add the variables from env | cut -d= -f1
to the "egrep" (ex. egrep -v "PATH|SHELL|TERM|xxxx")?
Since it's an EKS cluster perhaps it needs "AWS*" variables.
So if the first one fails, try run (from a new terminal window):
unset $(env | cut -d= -f1 | egrep -v "PATH|AWS")
open -a xbar.app
I had an idea, A bit of a ugly and resource heavy work-around instead of trying to figure out which environment variable is missing. Perhaps all can be imported.
Just add this line
eval $(/bin/zsh -c "env|egrep -v 'PS1|^_='")
After the other eval line(16)..
I should say it's probably better to figure out which environment variables are needed(https://github.com/matryer/xbar/issues/877#issuecomment-2115125740) instead of trying to import all.
Thanks for your suggestion @Raboo . I will try and give feedback.
OS: MacOS - Ventura 13.2.1 Processor: Apple M1 xbar version: 2.1.7-beta plugin: kubeswitcher.1m.sh by Elias Abacioglu (@Raboo on GitHub)
Description: I'm not sure what the issue is, but I'm trying to set up xbar with 'Kubeconfig Namespace & Context Switcher' plugin, and it's not working as expected when xbar is launched via a standard application.
Scenario 1: Not Working when xbar launched via applications / or started at login (Namespace and Context empty):
Scenario 2: Running the script in the terminal is producing the expected output:
the output is ok:
Scenario 3: Working as expected when xbar is launched via terminal:
Could it be related to https://github.com/matryer/xbar/issues/874 ? Any Hints? Thanks