loft-sh
"<external command>": executable file not found in $PATH, out: `` in the UI
What happened?
When trying to start up an environment I'm getting "executable file not found in $PATH" for a handful of different utilities. So far, the list is kubectl, docker, and docker-credential-osxkeychain. I've been able to work around the first two by setting the full path to them in the advanced config under their respective providers but the third one is blocking me from pulling images from a private repository. The really odd thing here is that it only happens when using the UI, in a terminal everything just works.
I have altering PATH in ~/.bashrc, ~/.bash_profile, ~/.profile, and ~/.zshrc with no change in behavior in the UI. I use zsh in the terminal with some success.
These binaries are in my path:
» which kubectl
/Users/me/.rd/bin/kubectl
» which docker
/Users/me/.rd/bin/docker
» which docker-credential-osxkeychain
/Users/me/.rd/bin/docker-credential-osxkeychain
I did see #665 which seems to be a similar problem on Windows when finding the AWS cli.
What did you expect to happen instead?
I expected the executables to be found by respecting one of the handful of configuration files mentioned above.
How can we reproduce the bug? (as minimally and precisely as possible)
My devcontainer.json:
{
"image": "ubuntu:latest",
"features": {
"ghcr.io/devcontainers/features/node:1": {}
}
}
Local Environment:
- DevPod Version: v0.5.19
- Operating System: mac 14.6.1 (23G93)
- ARCH of the OS: ARM64
DevPod Provider:
- Kubernetes Provider: 1.31
- Local/remote provider: docker
Anything else we need to know?
I am using Rancher Desktop for docker and kubectl which is why they aren't in one of the more typical locations although I wouldn't expect that to matter with having my path set correctly for other uses.
Hey @tpickett66, thanks for opening this issue. It looks like the problem here is that DevPod Desktop doesn't spawn in a shell, so it doesn't read the environment variables you set in any shell startup process, only the globally available ones. One way of fixing that would be to spawn a shell before starting the Desktop app and patching in the environment variables. I think it's expected behaviour at this point, specially so for a development tool
@pascalbreuninger thanks for the response, that all makes sense. Is there any plan to read in config files like this or provide some other way to configure $PATH more broadly? I wonder if it is possible to convince MacOS to launch a shell that execs the binary to get this for free.
At any rate, I was able to launch the UI from a terminal using /Applications/DevPod.app/Contents/MacOS/devpod & which did end up with all of the tools being available without issue.
One way this might be solved on MacOS (and maybe Linux) is to wrap the binary in a shell script. I was able to get things working correctly using the following script, that should be agnostic to which shell the user actually uses.
#! /usr/bin/env sh
exec $SHELL -c 'exec /Applications/DevPod.app/Contents/MacOS/DevPod'
I think this should be reopened - having to spawn this via a shell isn't very intuitive for something that's intended to be a GUI tool.
