matryer / xbar

Put the output from any script or program into your macOS Menu Bar (the BitBar reboot)
https://xbarapp.com
MIT License
17.45k stars 641 forks source link

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

Open brunopereira7 opened 1 year ago

brunopereira7 commented 1 year ago

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):

image

image

Scenario 2: Running the script in the terminal is producing the expected output:

image

the output is ok: image

Scenario 3: Working as expected when xbar is launched via terminal:

image

image

Could it be related to https://github.com/matryer/xbar/issues/874 ? Any Hints? Thanks

glowinthedark commented 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.

Raboo commented 2 months ago

@brunopereira7 PR https://github.com/matryer/xbar-plugins/pull/2035 will probably fix your issue.

Raboo commented 2 months ago

https://github.com/matryer/xbar-plugins/pull/2035 has been merged @brunopereira7 please test and confirm.

brunopereira7 commented 2 months ago

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): image image

Scenario 2: xbar is launched via applications or started at login. I can't switch the context and namespace. image

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!

Raboo commented 2 months ago

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.

Raboo commented 2 months ago

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?

brunopereira7 commented 2 months ago

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 😕

Raboo commented 2 months ago

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
Raboo commented 2 months ago

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.

brunopereira7 commented 2 months ago

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