Hi,

I just upgraded to 0.9.3 and kubectx is no longer working. When I run kubectx -c I get the following:

/usr/local/bin/kubectx: line 194: 77535 Killed: 9 kubectl config current-context

I downloaded 0.9.2 from the assets page and it works as expected.

I'm on MacOS 11.2.2 and (have always) installed kubectx/kubns from homebrew.

I just rebooted my machine for an unrelated issue and now it's working. I use fish shell and I think that got updated recently too. Might have been related.

The version of 0.9.2 I downloaded was the binary version: kubectx: Mach-O 64-bit executable x86_64

It looks like the version from homebrew is a shellscript though.

Here's the output from kubectx -c with DEBUG on:

+ IFS='
	'
+ SELF_CMD=/usr/local/bin/kubectx
+ KUBECTX=/Users/james/.kube/kubectx
+ main -c
+ [[ -z '' ]]
+ hash kubectl
+ KUBECTL=kubectl
+ [[ 1 -eq 0 ]]
+ [[ -c == \-\d ]]
+ [[ 1 -gt 1 ]]
+ [[ 1 -eq 1 ]]
+ [[ -c == \- ]]
+ [[ -c == \-\c ]]
+ kubectl config current-context
/usr/local/bin/kubectx: line 194: 91277 Killed: 9               kubectl config current-context```

and `kubens`:

```+ set -eou pipefail
+ IFS='
	'
+ SELF_CMD=/usr/local/bin/kubens
+ KUBENS_DIR=/Users/james/.kube/kubens
+ main
+ [[ -z '' ]]
+ hash kubectl
+ KUBECTL=kubectl
+ [[ 0 -eq 0 ]]
+ [[ -t 1 ]]
+ [[ -z '' ]]
++ type fzf
++ echo 0
+ [[ 0 -eq 0 ]]
+ choose_namespace_interactive
++ list_namespaces
++ local yellow darkbg normal
+++ tput setaf 3
++ yellow=''
+++ tput setab 0
++ darkbg=''
+++ tput sgr0
++ normal=''
++ local cur_ctx_fg cur_ctx_bg
++ cur_ctx_fg=''
++ cur_ctx_bg=''
++ local cur ns_list
+++ current_namespace
+++ local cur_ctx
++++ current_context
++++ kubectl config current-context
+++ cur_ctx=
+++ exit_err 'error getting current context'
+++ echo 'error getting current context'
error getting current context
+++ exit 1
++ cur=
++ exit_err 'error getting current namespace'
++ echo 'error getting current namespace'
error getting current namespace
++ exit 1
+ [[ -z '' ]]
+ echo 'error: could not list namespaces (is the cluster accessible?)'
error: could not list namespaces (is the cluster accessible?)
+ exit 1```

Also you're using the bash script version (not the binary version) from the Assets page right?

Can you run with environment variable DEBUG=1 and send output?

Hi,

I just upgraded to 0.9.3 and kubectx is no longer working. When I run kubectx -c I get the following:

/usr/local/bin/kubectx: line 194: 77535 Killed: 9 kubectl config current-context

I downloaded 0.9.2 from the assets page and it works as expected.

I'm on MacOS 11.2.2 and (have always) installed kubectx/kubns from homebrew.

There already is a file on disk that has the context file name. So what you’re trying to do is not only redundant, it creates multiple sources of truth for the same piece of information. This info doesn’t only change via kubectx. I recommend you examine the source code of the script to understand how it works.

Looks like 0.9.3 lost the ability to use the http_proxy environment variable to connect to the cluster.

Up to 0.9.2 I am able to just use:

$ echo $http_proxy
http://localhost:8888
$ kubens
default
www

On 0.9.3:

$ echo $http_proxy
http://localhost:8888
$ kubens
error: could not list namespaces (is the cluster accessible?): failed to list namespaces from k8s API: Get "https://<ip>/api/v1/namespaces?limit=500": dial tcp <ip>:443: i/o timeout

<ip> in this particular context is a GKE instance that only allows connections via a bastion. I have tinyproxy running in the bastion. localhost:8888 is provided by a SSH tunnel (ssh -f -L 8888:127.0.0.1:8888 -N my-bastion).

Yeah, that was it:

$ HTTPS_PROXY=$http_proxy ./kubens-0.9.3 
default
www

Awesome. Thank you @ahmetb!

yes, one can. i also can send pidgeons to aws with and encrypted stick to a dedicated staff member to decrypt, extract, re-encrypt and send back the information.

or i can just cache it locally, as it only changes on request.

this is a optimization feature, not a functional one.

Ok here’s from Go1.16 release notes:

The ProxyFromEnvironment function no longer returns the setting of the HTTP_PROXY environment variable for https:// URLs when HTTPS_PROXY is unset.

so you need to use HTTPS_PROXY from now on.

If you want to compare the checksums:

$ sha256sum kubens*
f479cb7c46e5e1844e57920ecc96489e1c2785c2e89e14abd8e6699b4323c0e4  kubens-0.9.2
58b9a3c4707ff39d7bed4c28afeeb1b1007bf9255c80ba6711bd3a515344baf9  kubens-0.9.3

$ ./kubens-0.9.2 
default
www
$ ./kubens-0.9.3 
error: could not list namespaces (is the cluster accessible?): failed to list namespaces from k8s API: Get "https://<ip>/api/v1/namespaces?limit=500": dial tcp <ip>:443: i/o timeout

The only other difference is that the 0.9.3 binary is 1172KB smaller, but I have no idea if that should mean something.

And you’re certain the same binary w/ 0.9.2 does not reproduce? If so, I have no reasonable expectation.

Golang, from the releases page: https://github.com/ahmetb/kubectx/releases/download/v0.9.3/kubens_v0.9.3_linux_x86_64.tar.gz

Is this the Go-based implementation or bash-based implementation of kubens? There are no code changes between the two versions mentioned https://github.com/ahmetb/kubectx/compare/v0.9.2...v0.9.3.

.. to use with other scripts or the PS1

You can use kubectl to get it.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

<!-- need_sender_cla -->

.. to use with other scripts or the PS1

Looks like 0.9.3 lost the ability to use the http_proxy environment variable to connect to the cluster.

Up to 0.9.2 I am able to just use:

$ echo $http_proxy
http://localhost:8888
$ kubens
default
www

On 0.9.3:

$ echo $http_proxy
http://localhost:8888
$ kubens
error: could not list namespaces (is the cluster accessible?): failed to list namespaces from k8s API: Get "https://<ip>/api/v1/namespaces?limit=500": dial tcp <ip>:443: i/o timeout

<ip> in this particular context is a GKE instance that only allows connections via a bastion. I have tinyproxy running in the bastion. localhost:8888 is provided by a SSH tunnel (ssh -f -L 8888:127.0.0.1:8888 -N my-bastion).

In case anyone is still interested in this functionality, the tool kubeswitch might solve the alias problem for you by transparently defining the alias without changing the underlying kubeconfig file. Full disclosure: I am the author of it.

Title is clear :)

Works like a charm :) Sagol!

Please try out the binary at https://github.com/ahmetb/kubectx/releases/tag/v0.9.3.

For the time being, both Homebrew and Krew distributions use the old bash-based implementation (as that’s intended). In the future, we’ll be packaging and distributing the binaries instead.

Of course I can

Can you test the binary if I provide one?