Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extraterm assumes WSL disk mounts are in /mnt and fails otherwise. #155

Closed
Kynolin opened this Issue Jan 11, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@Kynolin
Copy link

commented Jan 11, 2019

If using /etc/wsl.conf to change the root mount in WSL to something other than /mnt/c, such as /c, Extraterm still tries to use /mnt/c when initializing WSL. This causes the terminal to hang with a cursor that won't do anything, similarly to what happens if python3 is not installed in the WSL instance. Trying to open new tabs after the initial tab fails with a socket error, because wsl.exe immediately terminated when the first shell tried to open.

Example of /etc/wsl.conf that changes the mount point of Windows volumes, where /mnt/c would now instead be just /c.

[automount]
root = /
options = "metadata"

Here is what's being called when the WSL shell is initialized. It's doing this regardless of where C:\ is actually mounted.

wsl.exe PYTHONIOENCODING=utf-8:ignore python3 "/mnt/c/Program Files/Extraterm/resources/app/extensions/ProxySessionBackend/src/python/ptyserver2.py"

Here is what it looks like when it fails and a new WSL tab is opened.

[Window Title]
Error

[Main Instruction]
A JavaScript error occurred in the main process

[Content]
Uncaught Exception:
Error: This socket has been ended by the other party
    at Socket.writeAfterFIN [as write] (net.js:351:12)
    at WslProxyPtyConnector._sendMessage (C:\Program Files\Extraterm\resources\app\extensions\ProxySessionBackend\src\ProxyPty.js:212:27)
    at WslProxyPtyConnector.spawn (C:\Program Files\Extraterm\resources\app\extensions\ProxySessionBackend\src\ProxyPty.js:141:14)
    at WslProxySessionBackend.createSession (C:\Program Files\Extraterm\resources\app\extensions\ProxySessionBackend\src\WslProxySessionBackend.js:74:26)
    at PtyManager.createPty (C:\Program Files\Extraterm\resources\app\extraterm\src\main_process\pty\PtyManager.js:51:33)
    at handlePtyCreate (C:\Program Files\Extraterm\resources\app\extraterm\src\main_process\Main.js:752:30)
    at EventEmitter.handleIpc (C:\Program Files\Extraterm\resources\app\extraterm\src\main_process\Main.js:544:21)
    at emitTwo (events.js:126:13)
    at EventEmitter.emit (events.js:214:7)
    at WebContents.<anonymous> (C:\Program Files\Extraterm\resources\electron.asar\browser\api\web-contents.js:286:13)

[OK]

I have not tested, but I would also worry that this path is hardcoded if Extraterm were installed to a non-default path in Windows.

Also, unfortunately for me, I was testing with a WSL instance that had /c, and another that had /mnt/c but didn't have python3 installed yet, so both had the same issue for different reasons. I eventually found out what was happening by using Process Explorer with a 0.5 second update interval, and I repeatedly opened Extraterm and tried to hit right click and open the properties of the wsl.exe or conhost.exe subprocess before it was gone. It would be nice if the error could at the least be caught and explained in a more meaningful way. Fortunately, I had installed Extraterm at work before leaving, so I knew the issue was somewhere on my end at home.

This is the only instance of /mnt I see in the source.

./extraterm/extensions/ProxySessionBackend/src/WslProxySessionBackend.ts:    serverPath = "/mnt/" + serverPath.replace(/\\/g, "/").replace("C:", "c");

And that's coming from:

./extraterm/extensions/ProxySessionBackend/src/WslProxySessionBackend.ts:    let serverPath = path.join(SourceDir.path, "python/ptyserver2.py");

I'm no expert at finding/converting WSL paths to real Windows paths. I would assume there could be a check against /etc/wsl.conf or something storing the value of its 'root' which could be used in place of serverPath = "/mnt/" +.

@sedwards2009

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2019

Thanks for the detective work. I'll see what I can do to improve that situation. Hopefully once ConPTY is supported I'll be able to skip the whole Python middle man step and talk directly to WSL.

@Kynolin

This comment has been minimized.

Copy link
Author

commented Jan 15, 2019

Thanks! I hadn't heard of ConPTY, so I read the Microsoft blog about it. I now know why I've had such a hard time finding a good terminal in Windows! I'm glad Extraterm is able to do so well with WSL in its current state.

@sedwards2009

This comment has been minimized.

Copy link
Owner

commented Jan 15, 2019

Supporting ConPTY is pretty close on the dev map: #30 It should greatly improve terminal compatibility, reduce latency and also open the door to having shell integration work properly on Windows and maybe in PowerShell too.

@erhhung

This comment has been minimized.

Copy link

commented Feb 6, 2019

Ran into this exact issue trying to follow Nick's Docker in WSL setup instructions (https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly). I thought I could just recreate a symlink from /mnt/c to /c, but no go. For now, I just have to launch cmd.exe and then run bash directly.

@surenzxx

This comment has been minimized.

Copy link

commented Mar 30, 2019

Has this been solved yet? I just ran into this issue.

@sedwards2009

This comment has been minimized.

Copy link
Owner

commented Mar 31, 2019

@surenzxx next bug fix release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.