"Error: /bin/sh: docker: command not found" when opening YAML file

[XanderXAJ]

For anyone else that comes across this issue: This can be worked around by running code on the CLI.

Does this occur consistently? Yes
Repro steps:

1. Close VS Code.
2. Create a temporary project and open it in VS Code via the CLI:

   mkdir -p ~/tmp && touch ~/tmp/docker-compose.yml && code ~/tmp/docker-compose.yml

3. Verify that no error occurs.
4. Close VS Code.
5. Launch VS Code via Spotlight (⌘Space). It should re-open the same workspace automatically.
6. After a few seconds, note the error occurs.

I'm using Docker Desktop 2.3.0.4, which comes with Engine 10.03.12.

docker commands work fine in the integrated terminal, including docker context ls --format="{{json .}}". It is located (from the integrated terminal):

$ type docker
docker is /usr/local/bin/docker

This issue is probably occurring because Spotlight is providing a different (incomplete) environment that doesn't include /usr/local/bin on the PATH. Running code from the CLI works.

This works in the integrated terminal (configured to use Bash) because my environment files are sourced by the shell. However, since the extension is using /bin/sh, it won't be sourcing my .bashrc or .profile (which itself sources .bashrc, but only if the shell is BASH).

It's worth noting that even a plain sh launched with no environment works, which seems to indicate that the shell the extension launches has even less environment than that (!).

$ env -i sh -c 'docker --version'
Docker version 19.03.12, build 48a66213fe

$ env -i sh -c 'echo $PATH'
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.

One last note: the macOS /etc/profile contains the following code:

# System-wide .profile for sh(1)

if [ -x /usr/libexec/path_helper ]; then
        eval `/usr/libexec/path_helper -s`
fi

if [ "${BASH-no}" != "no" ]; then
        [ -r /etc/bashrc ] && . /etc/bashrc
fi

Running path_helper shows it also generates a PATH that would work here, so I'm guessing this is also not sourced by the sh run by the extension nor my environment-less sh above:

$ /usr/libexec/path_helper -s
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/puppetlabs/pdk/bin:<snip>"; export PATH;

This issue looks eerily similar to #2229 (closed due to not being reproducible).

Action: docker-context.initialize
Error type: 127
Error Message: Process 'docker context ls --format="{{json .}}"' exited with code 127
Error: /bin/sh: docker: command not found

Version: 1.5.0
OS: darwin
OS Release: 18.7.0
Product: Visual Studio Code
Product Version: 1.48.2
Language: en

Call Stack

ChildProcess.<anonymous> extension.bundle.js:3:173256
ChildProcess.emit events.js:203:13
maybeClose child_process.js:1021:16
Socket.<anonymous> child_process.js:430:11
Socket.emit events.js:203:13
Pipe.<anonymous> net.js:588:12

[bwateratmsft]

Yes, this is likely the same as #2229. I agree, Spotlight must not be giving it a complete environment. For executing that docker context inspect / docker context ls call, we're using Node's child_process.spawn. We use shell == true in the options. For environment, it inherits process.env by default (which is what we're using), which in this case means VSCode's environment variables. If Spotlight is leaving them out when launching VSCode, there's little that can be done.

@philliphoff Any ideas why this might be happening? I found this post which touches on the same issue--Spotlight not having the usual environment variables.

[karolz-ms]

@bwateratmsft that post you mentioned is 12 years old. Can't believe this is still an issue... 😔

[bwateratmsft]

I opened docker/for-mac#4875. Ultimately there's nothing the Docker extension can do about this, and it appears based on how old this issue is that Apple isn't interested. Perhaps the Docker Desktop for Mac installer can do something.

[XanderXAJ]

Thanks for looking in to this. I had wondered if it was a macOS/Spotlight issue.

It's a workaround, but might it be possible to have the shell launched by the extension run:

eval `/usr/libexec/path_helper -s`

This should then give a PATH usable enough to find docker.

I don't know the architecture here, so if it makes more sense for the Docker for Mac installer to fix it, go ahead with that. :)

Edit: In hindsight, it might make more sense for VS Code itself to do this. However, it's probably best it only does this when launched via Spotlight. I wonder if that's possible... Blah, it's cruddy needing to resort to workarounds for OS bugs/features.

[philliphoff]

@bwateratmsft No, I can't think of any reason for that behavior beyond what you've already uncovered. I don't see the same behavior on my Mac, but my default OS shell is ZSH so perhaps that has some magical effect.

[bwateratmsft]

I also was not able to reproduce on my Macbook, and I'm not using ZSH. @XanderXAJ The only thing the extension could really do is manipulate the PATH variable at runtime, which I'd be reluctant to do; I'm not sure what side effects that could have.

[AlexeyBoiler]

I have the same problem on this version of Desktop on Mac. iMac (21.5-inch, Late 2013) 10.15.3 (19D76) Catalina

[XanderXAJ]

Thanks everyone for looking in to it.

@bwateratmsft I would be similarly reluctant.

I suppose there's a couple of avenues to figure out what is different in mine and @AlexeyBoiler's setup versus everyone's that works!

• Reinstall the OS from scratch. The only macOS machine I use is a company one, so, unfortunately, I doubt I'll be able to follow this avenue.
• Check dotfiles (shell initialisation files) for differences.

Does anyone else customise their dotfiles? Mine are quite significantly customised. I have a ~/.bashrc and ~/.profile. I do not have ~/.bash_profile.

When invoked as a login shell, Bash launched as /bin/sh should source /etc/profile and ~/.profile. /etc/profile, as noted in OP, should set up the PATH to include /usr/local/bin. So I'm not sure if I'm going down the right path... But I'm not sure what other avenues to explore.

Edit: Also, as noted above, I'm using Bash. However, thanks to reports that ZSH and non-ZSH shells work, this might not be a key factor.