electron domterm doesn't start on WSL
lypanov opened this issue · comments
Relatively recently WSL switched to using the /c prefix rather than /mnt/c which breaks domterm on WSL. I'm use this ticket to track my work on debugging this.
Okay got this working now locally on the Windows 10 1909 version of WSL. The changes required are a wholesale switch in server.c from /mnt/c to /c. I also required a more lenient check for WSL under electron in the line:
if (is_WindowsSubsystemForLinux() && strstr(browser_command, ".exe") != NULL) {
Replacing this with:
if (is_WindowsSubsystemForLinux() && strstr(browser_command, "electron") != NULL) {
Has domterm working for me under WSL. Are you still actively working on the WSL version? If not I'd suggest simply moving to /c rather than complicating the code with checks. It's the standard now and will be in the coming future also by the looks of it.
Before I forget, the thing that flummoxed me the most was actually the location of settings.ini when running domterm from WSL / Electron. It being under AppData rather than XDG was unexpected. Not sure how to improve this alas. Bifurcating the settings / tmp directories seems feasible but I'm on very unsure ground to be making assumptions. What are your thoughts on this?
"Are you still actively working on the WSL version?"
Not on a frequent basis, but I am definitely actively maintaining it. (I normally run Fedora on my laptop, so I have to boot into Windows to test it.) I tested DomTerm on WSL not that long ago, and it seemed to work them.
If you send me a patch, I can test it out.
"It's the standard now and will be in the coming future also by the looks of it."
Do you have a link to an announcement about this, so I can better understand the timing, versions, and implications?
"the thing that flummoxed me the most was the location of settings.ini when running domterm from WSL / Electron. It being under AppData rather than XDG was unexpected."
That is documented in the manual.
The reason for using AppData is so DomTerm can be more usable from plain Windows tools and applications. You might require WSL to build and install DomTerm, but I'd like it be to useful for non-WSL Windows tools and applications. As the Windows terminal system improves to be more Unix-like, it may make sense to run Windows console applications under DomTerm.
"It's the standard now and will be in the coming future also by the looks of it."
Do you have a link to an announcement about this, so I can better understand the timing, versions, and implications?
Looking deeper appears I was horribly wrong about this. Either way, looks like the best modern fix for domterm is for it to execute "wslpath /" and check the response. On my machine the response is "/c/" due to my root = "/" setting in /etc/wsl.conf (which have no recollection of setting! but lets blame sleep deprivation). The old default used to be "/mnt" root anyway so it could be modified to automatically use wslpath and fall back to /mnt if not available. I can look into making a patch if you like this path.
"Looking deeper appears I was horribly wrong about this."
We've all managed to confuse ourselves in similar ways.
"looks like the best modern fix for domterm is for it to execute "wslpath /" "
Maybe, wslpath -u c: or something like that?
Maybe,
wslpath -u c:or something like that?
"wslpath c:" works. Without the slash it doesn't work. -u is default. Does this path sound sane? I can come up with a quick patch if yes.
Yes, that sounds reasonable.
Closing this as by default everything is fine, it's just on top of my apparently weird WSL installation that it was broken. Feel free to re-open if you feel it important to make it work with either configuration. I won't get around to providing this patch as I'm no longer using DomTerm.