Omnisharp on Windows fails to run likely because of spaces in user name

[derekthecool]

I believe this to be an issue that should be addressed by maintainers of mason.nvim.

• Yes

Why do you think this is an issue with mason.nvim?

I am getting errors with the omnisharp client quitting on start up. Upon looking through the lsp.log it appears that it does not like the space in my user name.

[START][2022-09-21 21:24:01] LSP logging initiated
[ERROR][2022-09-21 21:24:01] ...\vim\lsp\rpc.lua:734	"rpc"	"C:\\Users\\Derek Lomax\\AppData\\Local\\nvim-data\\mason\\bin\\omnisharp.CMD"	"stderr"	"'C:\\Users\\Derek' is not recognized as an internal or external command,\r\noperable program or batch file.\r\n"

So, I'd guess the most likely source of the issue is mason.nvim because the problem seems to stem from an issue with handling spaces in the omnisharp.cmd scripts (one is in the bin directory, the other is in the packages directory)

Neovim version (>= 0.7)

NVIM v0.8.0-dev-1120-ga0e6e767a
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

Operating system/version

Windows 10

I've manually reviewed logs to find potential errors

• Yes

I've recently downloaded the latest plugin version of mason.nvim

• Yes

Affected packages

omnisharp (not the mono package)

Problem description

The omnisharp client quits on startup. Again here are the logs from lsp.log. There are no relevant logs from mason.log.

[START][2022-09-21 21:24:01] LSP logging initiated
[ERROR][2022-09-21 21:24:01] ...\vim\lsp\rpc.lua:734	"rpc"	"C:\\Users\\Derek Lomax\\AppData\\Local\\nvim-data\\mason\\bin\\omnisharp.CMD"	"stderr"	"'C:\\Users\\Derek' is not recognized as an internal or external command,\r\noperable program or batch file.\r\n"

Using LspInstaller for omnisharp worked great. Also, for reference I'm getting no issues with running sumneko lua lsp.
Looking at differences in the files in the mason bin directory:

• I see the file mason\bin\omnisharp.cmd calls another cmd script
• While the the file lua-language-server.cmd calls an executable

Steps to reproduce

1. Have your windows user name include a space
2. Download and configure omnisharp
3. Open any csharp file this is part of a solution and project
4. Watch the LSP quit on startup

Actual behavior

LSP quits on startup.

Expected behavior

I expected omnisharp to start working once I opened my csharp file program.cs

Healthcheck

mason: require("mason.health").check()
========================================================================
## mason.nvim report
  - OK: neovim version >= 0.7.0
  - WARNING: **Go**: not available
  - WARNING: **cargo**: not available
  - WARNING: **luarocks**: not available
  - WARNING: **Ruby**: not available
  - WARNING: **RubyGem**: not available
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - OK: **npm**: `8.15.0`
  - OK: **node**: `v16.17.0
`
  - OK: **python3**: `Python 3.10.7
`
  - OK: **pip3**: `pip 22.2.1 from C:\Users\Derek Lomax\scoop\apps\python\current\lib\site-packages\pip (python 3.10)

`
  - WARNING: **javac**: not available
  - WARNING: **java**: not available
  - WARNING: **julia**: not available
  - ERROR: **wget**: not available
  - OK: **curl**: `curl 7.79.1 (Windows) libcurl/7.79.1 Schannel
`
  - ERROR: **gzip**: not available
  - OK: **tar**: `bsdtar 3.5.2 - libarchive 3.5.2 zlib/1.2.5.f-ipp 
`
  - OK: **python**: `Ok`
  - OK: **pip**: `pip 22.0.4 from C:\Python38\lib\site-packages\pip (python 3.8)

`
  - WARNING: **JAVA_HOME**: not available
  - OK: GitHub API rate limit. Used: 0. Remaining: 60. Limit: 60. Reset: 9/21/2022 10:48:09 PM.

Screenshots or recordings

I don't have any relevant items for this.

I would like to say great job on this project. This is more than a plugin, this is like a candy store!

It is quite impressive what you've created! I am in awe!

[derekthecool]

Additional information I think may be important. I'm using the auto config option from mason-lspconfig.nvim.

This results in LSP setup like this from LspInfo:

 Detected filetype:   cs
 
 0 client(s) attached to this buffer: 
 
 Other clients that match the filetype: cs
 
 Config: omnisharp
 	filetypes:         cs, vb
 	root directory:    C:\Users\Derek Lomax\source\repos\Freeus.Tools\BXFota\BWFota
 	cmd:               C:\Users\Derek Lomax\AppData\Local\nvim-data\mason\bin\omnisharp.CMD -z -s C:/Users/Derek Lomax/source/repos/Freeus.Tools/BXFota --hostPID 16256 DotNet:enablePackageRestore=false --encoding utf-8 --languageserver FormattingOptions:EnableEditorConfigSupport=true Sdk:IncludePrereleases=true
 	cmd is executable: true
 	autostart:         true
 	custom handlers:   

[derekthecool]

Today I tried using my nvim-lsp-installer setup again with omnisharp to compare.

Everything is still working fine there.
This is what I getting from LspInfo:

 Detected filetype:   cs
 
 1 client(s) attached to this buffer: 
 
 Client: omnisharp (id: 1, pid: nil, bufnr: [1])
 	filetypes:       cs, vb
 	autostart:       true
 	root directory:  C:/Users/Derek Lomax/source/repos/Freeus.Tools/BXFota
 	cmd:             dotnet C:\Users\Derek Lomax\AppData\Local\nvim-data\lsp_servers\omnisharp\omnisharp\OmniSharp.dll --languageserver --hostPID 16700
 
 Configured servers list: jedi_language_server, powershell_es, sumneko_lua, lemminx, omnisharp

So comparing with the mason setup it seems a likely error spot is from the second path -z -s C:/Users/Derek Lomax/source/repos/Freeus.Tools/BXFota. This path also seems to be using / instead of \ for directory separator as well.

[williamboman]

Hello! Ah hm something must be up with the .cmd executable Mason writes. Will need to investigate next time I'm at a Windows machine.

Just some semi-related trivia - the cmd as displayed in :LspInfo is not subject to normal shell-like rules (where whitespace and escaping is important, at least in *NIX shells). It's just a string representation of the command, which behind the scenes is a list ({ "dotnet", "C:\Users\Derek Lomax\…", … } ). This list is passed on to libuv which in turn pass on the arguments, in their correct position, to platform-specific calls (exec(3) on *NIX).

So with the above explanation I believe the cmd itself is fine, the issue is in the contents of the C:\Users\Derek Lomax\AppData\Local\nvim-data\mason\bin\omnisharp.CMD script.

edit: Oh and the path separators get normalized somewhere along the way as well.

[derekthecool]

Thanks for your response. And thanks again for this amazing project!

If you believe the issue is with the CMD file I will try working to solve it as well.
My bat/CMD scripting is not great, I much prefer powershell but I'll give it a go.

I found today that the powershell lsp has a similar error. The LspLog shows the same error. I then tested powershell on Linux and it worked.

[williamboman]

Ok so I've finally figured out where the problem is (relevant Node.js issue here: nodejs/node#7367). This is a bit of a weird edge case on Windows in libuv where if both the command and one or more arguments contain a space, it freaks out with the error message in your logs. Omnisharp in particular will include the workspace directory as an argument to the language server command so it will run into this 100% of the time. Other language servers usually don't have any arguments (or if they do they're generally just options like --stdio).

Short answer is: don't use spaces in directory names, especially your home directory. You'll run into weird issues like these.

Slightly longer answer is: imo this is not really an issue that can/should be solved on a plugin-level but rather users would have to override default behaviour to work around this issue. At the very least, it's not an issue with Mason. What you can do to work around this is to override the cmd for omnisharp to start the server via cmd.exe (this approach is exactly the same as what shell: true does if you're familiar with Node.js APIs):

lspconfig.omnisharp.setup {
  cmd = { "cmd.exe", "/C", "omnisharp" } -- The "omnisharp" executable is provided by Mason and will be found by cmd.exe
}

The lspconfig configuration for omnisharp will then append all necessary arguments to your cmd.

[derekthecool]

Thanks for looking into this! I understand this is a weird edge case.

I always avoid spaces in my file paths. But unfortunately I am unable to change this directory on my work computer.

But since you've narrowed it down to the libuv library, perhaps I'll see if I may be able to help find a fix for that.

As for your suggested work around... I found that it still fails in the same way as if I had not added any extra config.
But something I had not tried before is to just choose a project directory on another drive I can avoid the space in the path.