ZSH support

[EItanya]

Support spawning ZSH sub shells.

As mentioned in the recent blog post, zsh support is planned for the future.

[EItanya]

Wanted to create an issue to track this feature as this would be an absolutely game changing feature for me personally. From the FISH issue it sounds like this is already being worked on, but if not I would be more than happy to give it a try. I am not rust expert by any means, but I have done some in the past for work.

[sbstp]

I'm working on it right now. There's three major components to zsh support.

1. reliably detect which shell is in use
2. be able to start zsh with a custom rc file
3. be able to add a preexec hook before commands run

I've investigated these and they seem possible to do with zsh. I'm currently working on detecting which shell is in use.

[EItanya]

Sounds good to me, as I said, let me know if there is anything I can do. Maybe to start have a configuration option for the type of shell. And then add in auto discovery right after?

I am a pretty heavy zsh user, 2. should be fairly easy, no idea about 3

[sbstp]

Hey I think ZSH support is in a good shape now. It works well on my Linux machine. Can you try it out and let me know if you have any issues? You can compile the support-zsh branch to test it.

[EItanya]

Of course!
Here is the result without setting to zsh in the settings file.

~/src/rust/kubie/target/debug on  support-zsh
✗ ./kubie ctx
Error: Could not detect shell in use

However, when I set shell: zsh in ~/kube/kubie.yaml it works!

Can debug the detection in a little bit, need to finish up some work on my end first. Might either be OSX details, or a peculiarity with my machine.

Thanks so much for adding ZSH support so quickly though. This tool is really a game changer, and editing one line of yaml is not a big deal at all!

[sbstp]

I asked my buddy to test it on his Mac, and he also got this error. It seems like the ps command doesn't behave the same on Mac. I could probably read the SHELL variable, but it is not set by the shell, it's set at the user level. Would still be better than nothing!

I'm trying to setup a Mac virtual machine to test kubie on it.

[sbstp]

Ok so I ran ps on the Mac virtual machine... The zsh binary is called -zsh on Mac for some reason! WTF moment, but easy to fix.

[sbstp]

@EItanya can you try again? I searched on the net and this is because zsh is a login shell, so ps adds a dash before. I added a commit to trim it.

[EItanya]

Just tried again, that's working for me!
A couple of things to note however:

My shell is now displaying 2 separate prompts, this may have to do with my particular setup, because I am running [starship]https://github.com/starship/starship.

Also, as you can see from the picture above, my starship prompt does not transition to the new kube context until after I run a command. It seems like the ENV var changes you are applying don't take proper affect until after a single command is run. As far as the double display I cannot say.
Is kubie adding this:

[gke_solo-corp_us-central1-a_standard-cluster-1|default]

Overall though working great, just those 2 small things

[EItanya]

Okay, just read through the code, based on my limited knowledge of the zsh impl of spawn_shell it seems like it is in fact creating a prompt, which I just verified locally, going to dig a bit into what might be causing the lag in in my prompt. Maybe a setting to disable the prompt from kubie? I would be more than happy to add that in.

[sbstp]

Yeah kubie adds the [gke_solo-corp_us-central1-a_standard-cluster-1|default] prompt. I could add a setting to disable it altogether.

[EItanya]

Yea that would be awesome! Not sure how common this will be, but I know for instance that most people in my office also have their own prompts, so 🤷‍♂

[sbstp]

Kubie is meant to prepend its prompt to whatever prompt is configured, so it shouldn't break your prompt.

I'm not sure why the interaction with starship is weird like this, it might just be because the kubie prompt and the starship prompt combine to something too long.