Support /bin/bash as an SSH command about k9s HOT 8 CLOSED

A simple config file in $HOME/.k9s might be a good place for user preferences.

I'd also suggest renaming 'SSH' to 'Shell', since SSH isn't actually involved.

AND... I'd also like to say that k9s is very cool :)

from k9s.

Ah! Thank you both for reporting back! I've opted for sh since most containers will have it. Bash may not be available on some containers. Hence this default. I could add it in the config but it may not always work??

from k9s.

I could add it in the config

Where is this config?

from k9s.

Indeed, I think /bin/sh would always work, so it's the best option. To support a preferred shell, k9s would maybe have to try the preferred shell first, then fall back to /bin/sh if unsuccessful. Might be going too far?

In any case, it would still be good to remove any references to SSH as this is confusing.

from k9s.

I've remove the ssh mentions for shell. I don't think I feel canning this in the config would be right tho... I am going to punt for now given

1. Lots of container to support bash hence sh is more generic.
2. Some container don't even offer a sh ie scratch image
3. If the container does have bash. You can easily start one from sh

Sounds Ok?

from k9s.

what about a new shortcut: CTRL+S for SH and CTRL+SHIFT+S for bash? or the other way around :)
you wont cover all the cases anyway.

from k9s.

Added bash support. The runtime will try bash first if not successful will use sh. Same shortcut. Please see 0.2.1. Tx!!

from k9s.

This seems to have the same problem that viewing logs had before the 0.2.1 release. Here are my debug-level logs when I try to shell to a host, with some obfuscation for the api host:

INFO[2019-03-03T06:58:42-08:00] 🐶 K9s starting up...
DEBU[2019-03-03T06:58:42-08:00] Active Context `hyde`
DEBU[2019-03-03T06:58:42-08:00] Connecting to API Server https://api.hyde.example.com
INFO[2019-03-03T06:58:43-08:00] ✅ Kubernetes connectivity
DEBU[2019-03-03T06:58:43-08:00] [Config] Saving configuration...
DEBU[2019-03-03T06:58:43-08:00] Reloading RawConfig...
DEBU[2019-03-03T06:58:43-08:00] Context swith detected...
DEBU[2019-03-03T06:58:43-08:00] Reloading RawConfig...
DEBU[2019-03-03T06:58:43-08:00] Validating favorites...dev
DEBU[2019-03-03T06:58:44-08:00] Connecting to API Server https://api.hyde.example.com
DEBU[2019-03-03T06:58:44-08:00] [Config] Saving configuration...
DEBU[2019-03-03T06:58:44-08:00] Validating favorites...dev
DEBU[2019-03-03T06:58:49-08:00] >> TableView handled s
DEBU[2019-03-03T06:58:49-08:00] Shell args[exec -it -n dev logstash-relay-57db57457-fzxqb -- sh]
DEBU[2019-03-03T06:58:49-08:00] Running command > /Users/tlyons/bin/kubectl exec -it -n dev logstash-relay-57db57457-fzxqb -- bash
DEBU[2019-03-03T06:58:50-08:00] Command return status exit status 1
DEBU[2019-03-03T06:58:50-08:00] Running command > /Users/tlyons/bin/kubectl exec -it -n dev logstash-relay-57db57457-fzxqb -- sh
DEBU[2019-03-03T06:58:50-08:00] Command return status exit status 1
ERRO[2019-03-03T06:58:50-08:00] Command exited: *exec.ExitError exit status 1 [exec -it -n dev logstash-relay-57db57457-fzxqb -- sh]
DEBU[2019-03-03T06:58:53-08:00] >> AppView handled key: q

In my case, this is probably the configuration that's causing the above commands to fail:

$ grep current-context ~/.kube/config
current-context: ren

Since you made the adjustment that you no longer modify the "current-context" setting in ~/.kube/config, you need to always explicitly set the --context foo on the kubectl commandline. (And I REALLY like that you don't change the config file any more. It was frustrating to have the context changed underneath kubectl commands running in other terminal windows.)

from k9s.