Open mkielar opened 2 years ago
So, I did a little digging, and it seems this issue is related to this code fragment: https://github.com/OmniSharp/omnisharp-vscode/blob/5e48576134ef9b16226dcd9db400088f99e8a7de/src/common.ts#L95-L97
When the omnisharp first initializes, it opens a VS Code Terminal (which in this case runs my WSL Bash), and then observes stderr
of that terminal, and fails if it sees anything it doesn't like in stderr
. The thing is my .bashrc
caused some messages to appear in stderr
, but other than that it initialized properly.
When I commented out the quoted section, Omnisharp initialized properly.
I'll try to make by .bashrc
and VSCode like each other again to prevent polluting stderr
, but that logic in getUnixChildProcessIds
is quite peculiar, and I wonder what purpose it serves?
I think you can reproduce this issue by echo'ing anything to stderr
in your .bashrc
and observing Omnisharp no longer initializes propely.
One of our users hit this in https://github.com/microsoft/vscode-docker/issues/3553
The original Unix/C semantics is that stdout
is for program output and stderr
is for diagnostic, human-consumption messages. We should NOT assume that presence of data in stderr
implies error condition.
Environment data
dotnet --info
output:VS Code version:
1.61.0
C# Extension version:v1.23.16
OmniSharp log
Steps to reproduce
fedoraremix 34.5.6 Final
(https://github.com/WhitewaterFoundry/Fedora-Remix-for-WSL)Expected behavior
Omnisharp should initialize and provide intellisense.
Actual behavior
Omnisharp does not initialize, and there's the
Cannot read property 'isWindows' of undefined
error in the log. Seems like Omnisharp is unable to identify the platform when ran fromfedoraremix
. I'm seeing no such issued when I run the same steps with Ubuntu 20.04 LTS.