[WIP] Use WSL PHP for validation

[codeguy]

Related to #22391

WORK IN PROGRESS. DO NOT MERGE YET.

I am having an issue fetching the standard output from the spawned validator process. What I am doing is spawning a cmd.exe process, and that spawns a bash.exe process who in turn runs "php -l -n -f /path/to/file/to/validate.php". However, this callback is never called:

https://github.com/codeguy/vscode/blob/feature-wsl-php-validator/extensions/php/src/features/validationProvider.ts#L284-L287

I have not hooked up custom configuration settings yet. I am simply forcing VSCode to use WSL php for validation with these temporary lines:

https://github.com/codeguy/vscode/blob/feature-wsl-php-validator/extensions/php/src/features/validationProvider.ts#L252-L265

Do you have any thoughts why I am not getting any stdout?

I have seen this issue with WSL:

cpdt/slinky#11

Correct issue to reference is microsoft/WSL#2

But that was apparently resolved with latest code pushed out with Creators Update.

Thoughts?

Wasn't sure which branch to send PR against, so using master for now. I can always re-submit.

[mention-bot]

@codeguy, thanks for your PR! By analyzing the history of the files in this pull request, we identified @dbaeumer and @egamma to be potential reviewers.

[codeguy]

Same issue happens if I directly invoke bash with childProcess.spawn('bash', ['-c "php -l ..."'], options); The standard output callback is never called.

[codeguy]

Also, if I directly run bash -c "php -l -n -f /mnt/c/Users/me/file.php" in console, it works. Does not work when invoked in a Node.js script.

[khouzam]

Hey @codeguy

We'll look at it from the console/WSL side.

[codeguy]

@khouzam I've gotten stdout from bash to work. However, I'm now seeing my Linux paths being auto-converted back to C:\ style path... not sure if Node is doing this, or Bash, or what. Doesn't happen when I invoke directly in console. It is happening in Node when compiled app is run via Electron. See screen cap.

[codeguy]

Found a solution!!! I'll hook up custom VSCode php.validate.* settings tomorrow and squash commits.

[codeguy]

I've hooked up config settings. You can use these to validate via WSL shell:

{
    "php.validate.executablePath": "C:\\Windows\\sysnative\\bash.exe",
    "php.validate.executableIsShell": true,
    "php.validate.executableArgs: "-c",
    "php.validate.shellExecutablePath: "/usr/bin/php"
}

I still need to complete these tasks:

• Ensure validation works with onType trigger mode
• Ensure code formatting adheres to contributor guidelines
• Squash commits

[dbaeumer]

@codeguy thanks a lot for looking into this. A couple of first remarks: we should implement the feature in a way that it can be used to execute php in a shell as well. So the path conversion to WSL should only happen in Windows and only if the shell is bash.exe.

To make it consistent with other settings we have for tasks.json I would prefer something like this:

{
    "php.validate.executablePath": "/usr/bin/php",
    "php.validate.runInShell": {
        "executable": "C:\\Windows\\sysnative\\bash.exe",
        "shellArgs": [ "-c" ]
    }
}

we should also allow to use a boolean for "php.validate.runInShell" and then use the platforms default shell. Something like:

{
    "php.validate.executablePath": "/usr/bin/php",
    "php.validate.runInShell": true
}

[codeguy]

@dbaeumer Thanks for the feedback. Most recent commit standardizes settings. You can now use:

{
    "php.validate.executablePath": "/usr/bin/php",
    "php.validate.runInShell": true
}

This will default to C:\Windows\sysnative\bash.exe with arguments -c. You could also use:

{
    "php.validate.executablePath": "/usr/bin/php",
    "php.validate.runInShell": {
        "shellArgs": ["-c"],
        "shellExecutable": "C:\\Windows\\sysnative\\bash.exe"
    }
}

I also attempted to declare the possible configuration settings in extensions/php/package.json, but I was unsure how/where to add localized strings for configuration setting descriptions. So I just used English for now.

[codeguy]

@dbaeumer I'm going to remove the last remaining console.log debugging stuff, and then squash my commits later today. Do you have any further feedback on the code in this PR?

[dbaeumer]

@codeguy more feedback:

• regarding nls: you can use %key% as a value for a string in the package.json and then add the actual string into package.nls.json. You might want to use php.validate.executablePath as an example.

• if runInShell is a boolean then we should use the platforms default shell for Windows, Mac and Linus. The current code simply uses bash for Windows. That path doesn't exist under Mac, Linux

• we should only convert file paths from Windows to Linux when running in WSL. If we run in cmd.exe under Windows for example the paths must still be Windows.

And thanks again for looking into this.

[codeguy]

I keep forgetting this is cross-platform :) Will take care of these issues tonight.

[codeguy]

@dbaeumer

Latest commits include the following changes:

1. I use correct %key% syntax in package.json and package.nls.json
2. If runInShell is a boolean...
   • If platform is win32, I use C:\\Windows\\sysnative\\bash.exe
   • Else I use default shell (i.e. process.env.SHELL else /bin/bash)
3. File paths are converted from Windows to Linux if and only if platform is win32 and shell is bash.exe.

[dbaeumer]

I think we can't assume that a user wants the bash if runInShell is set to true. I would expect that the user wants to use what is defined in ComSpec under Windows.

And then we need to set the shellArgs accordingly as well since -c will not work with cmd.exe nor with powershell.exe. For cmd.exe this is /C and for PowerShell it is /Command

[dbaeumer]

We can't simply test bash.exe here since git under Window installs a bash.exe as well. We either need to test for the full path or better see how bash from git mount the drive and do the path magic as well.

[dbaeumer]

Added some comments. Here is a screen shot how git bash handles this:

[codeguy]

Haven't forgotten about this. Haven't had time lately. Will try to wrap this up this week.

[codeguy]

Attempting to re-create local dev environment to work on this pull request. Running into this bug #29310

[codeguy]

I suspect I'm not knowledgeable enough in the Windows environment yet to auto-detect the various possible shells and how to differentiate Git bash.exe from WSL bash.exe. Would you accept and merge this PR were it only to allow validate.runInShell as an object requiring the VSCode user to explicitly define the Windows executable path, shell binary, and shell args?

[codeguy]

I've made an attempt to honor ComSpec setting. I'm also setting correct shell args if cmd.exe, powershell.exe, or bash.exe. If bash.exe, I'm inspecting bash.exe --version output to detect "msys", and if found, applying correct filepath transform for Git Bash vs. WSL Bash.

[dbaeumer]

@codeguy sorry for not coming back earlier but I was very busy with Tasks 2.0.0. And now I am about to heading out on vacation until beginning of August. Will look at the PR then.

[benjaminprojas]

Would love to see this added. Any update on the progress?

[codeguy]

My work on this has stalled and I do not have availability any time soon to continue work on it. Someone is welcome to pick up where I left off or work on an alternative PR.

[mazyvan]

any update on this?

[dbaeumer]

There is now a general item on the VS Code roadmap to improve WSL support.

[mazyvan]

Excuse me, could you be more specific? What are the configurations?

[dbaeumer]

We have not agreed on a concrete set of scenarios yet (see https://github.com/Microsoft/vscode/wiki/Roadmap#wsl-support) But being able to launch tooling in WSL (for example php executable is on the list).