It always sent the spawn notice with WSL setting

[Kaol-Fu]

Summary

When I open yml files, the VS code always sent me a notice with "spawn C:\WINDOWS\system32\cmd.exe ENOENT", and doesn't get any extension features work.

I have specified the WSL path for the vscode-ansible settings like these:

"ansible.ansibleLint.path": "\\wsl$\\Ubuntu-20.04\\usr\\bin\\ansible-lint",
"ansible.ansible.path": "\\wsl$\\Ubuntu-20.04\\usr\\bin\\ansible",
"ansible.ansiblePlaybook.path": "\\wsl$\\Ubuntu-20.04\\usr\\bin\\ansible-playbook",
"ansible.python.interpreterPath": "\\wsl$\\Ubuntu-20.04\\usr\\bin\\python3",

Does the extension not support the setting like this way?

Extension version

0.4.5

VS Code version

1.59.1

Ansible Version

# ansible --version                                                                                             
ansible 2.9.6
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/kaol/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.10 (default, Jun  2 2021, 10:49:15) [GCC 9.4.0]

OS / Environment

Windows 10, WSL (Ubuntu 20.04.3 LTS), ansible-lint 4.2.0

Relevant log output

No response

[wohnout]

I am experiencing same issue ...

[tj5475]

Same here

[rothman857]

Same issue here, but only when running vscode in Windows (outside WSL). If I disable ansible-lint (setting id ansible.ansibleLint.enabled), the error goes away. Looks like the plugin might be trying to run linting on a Windows machine (without Ansible/ansible-lint installed)

[priyamsahoo]

Hey- Thanks for this. The code base is currently going through a major refactoring effort. We don't expect this to be an issue when that work is done. This will remain open until sometime after the new version is released. Please check back in the next month or so.

[Kaol-Fu]

Same issue here, but only when running vscode in Windows (outside WSL). If I disable ansible-lint (setting id ansible.ansibleLint.enabled), the error goes away. Looks like the plugin might be trying to run linting on a Windows machine (without Ansible/ansible-lint installed)

Yes, if we disable the ansible-lint, the error will disappear. But we still cannot get any extension features worked.

[webknjaz]

There's a high chance that this will get fixed after https://github.com/ansible/ansible-language-server/pull/5 is merged.

[Sean-OConnor-VA]

After update on 3 Nov 21 and above pull request was merged - this issue persists spawn C:\WINDOWS\system32\cmd.exe ENOENT

[excitare]

After a cursory look I guess this error could be due to child_process.exec calling cmd.exe and cmd not being able to call or find the executable in WSL. Therefore the error ENOENT (No such file or directory). I think the commandRunner.runCommand won't ever find the ansible executable on Windows with WSL.

C:\>cd \\wsl$\Ubuntu\usr\bin\
'\\wsl$\Ubuntu\usr\bin\'
CMD does not support UNC paths as current directories.

You would need to call ansible via wsl.exe <path to ansible in WSL> (e.g. wsl.exe /usr/bin/ansible), which is not possible to set via the ansible.ansible.path setting.

After researching for a while and installing WSL Remote I found this in the README:

For Windows users, this extension works perfectly well with extensions such as Remote - WSL and Remote - Containers.

Oh well. I should've read more carefully.

Configuring Remote WSL.

[webknjaz]

@1p1eq11 did it work for you with WSL2 or WSL1?

[excitare]

@webknjaz I am using ~~WSL2~~ WSL1.

[webknjaz]

Oh, interesting. I wasn't sure if we would be able to run tests in such an env (GitHub Actions does not support WSL2).