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

Support Windows Subsystem for Linux (WSL) #52

Closed
wants to merge 2 commits into from

Conversation

x11x
Copy link

@x11x x11x commented May 25, 2019

WSL is a proper Linux distro so process.platform === 'linux'. However, most people won't have an X server installed so xsel won't work.
But WSL can call native windows executables and the fallback/clipboard_*.exe programs work fine.
Thus, if we use the windows lib on WSL, everything just works.
Code for checking whether we're running in WSL is based on https://stackoverflow.com/a/43618657, which has a quote from a WSL dev as the source.

WSL is a proper Linux distro so `process.platform === 'linux'`. However, most people won't have an X server installed so `xsel` won't work.
But WSL can call native windows executables and the fallback/clipboard_*.exe programs work fine.
Thus, if we use the windows lib on WSL, everything just works.
Code for checking whether we're running in WSL is based on https://stackoverflow.com/a/43618657, which has a quote from a WSL dev as the source.
@notlmn
Copy link

notlmn commented May 25, 2019

There's https://github.com/sindresorhus/is-wsl you can use to check if the script is run in a WSL environment.

@x11x
Copy link
Author

x11x commented May 25, 2019

Thanks. I will change to use that.
Lint is failing too, sorry will fix that.

@x11x
Copy link
Author

x11x commented May 25, 2019

Sorry, this isn't ready to merge yet. It was a simple change and worked in my environment but I realise now that its not a complete solution.
The native fallbacks work from within WSL as I have said above, but they need to be wrapped in cmd.exe /q /c.
I have tried the shell: true option of execa but that does not seem to work. It might be simplest to just manually wrap the calls to the fallback binaries inside cmd.exe /q /c in lib/windows.js when running in WSL.
I will change that and reopen.

It worked perfectly when I was testing before because ... shells and terminal environments on Windows are complicated these days. (I have node installed in both windows and WSL, and I had clipboardy installed in both; WSL was using some component from the windows install).

@x11x
Copy link
Author

x11x commented May 25, 2019

What I said above about cmd.exe is incorrect. The problem is that the fallback binaries need to be on a letter drive. I have provided more information in #53

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants