Issue with profile or environment variables? Plugin only works if xbar is launched via terminal

[Bruno Miguel Pereira]

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 #874 ? Any Hints?
Thanks

[glowinthedark]

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.

[Elias Abacioglu]

@brunopereira7 PR matryer/xbar-plugins#2035 will probably fix your issue.

[Elias Abacioglu]

matryer/xbar-plugins#2035 has been merged @brunopereira7 please test and confirm.

[Bruno Miguel Pereira]

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!

[Elias Abacioglu]

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.

[Elias Abacioglu]

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?

[Bruno Miguel Pereira]

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 😕

[Elias Abacioglu]

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

[Elias Abacioglu]

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(#877 (comment)) instead of trying to import all.

[Bruno Miguel Pereira]

Thanks for your suggestion @Raboo . I will try and give feedback.