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

Does not work when installed by npm on WSL #53

Closed
x11x opened this issue May 25, 2019 · 3 comments · Fixed by #59
Closed

Does not work when installed by npm on WSL #53

x11x opened this issue May 25, 2019 · 3 comments · Fixed by #59
Labels
bug 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted

Comments

@x11x
Copy link

x11x commented May 25, 2019

Issuehunt badges

In WSL, you can use native windows executables and native linux executables side by side in the same shell. When you install linux node/npm and install clipboardy, it doesn't work as it thinks its on Linux and tries to use xsel, but there is no X server (unless the user installed one).

I had a go at adding support for this in #52 but have closed that as its not a complete solution. WSL support is simple in theory. WSL can run native windows binaries and I can confirm that the fallback executables provided by this module work inside WSL.

The trick is, native windows binaries need to be on a letter drive to run (e.g. C: drive).

This is where things start to get complicated with different paths and environments. WSL has its own filesystem but can also access the standard letter drives under /mnt/c and so on. When clipboardy is installed in WSL, npm installs those .exe files in the fallback directory but these are in a filesystem that is internal to WSL and not accessible to the rest of Windows. Like I said, they need to be on a letter drive where windows can access them.

To make it work when installed in WSL:

  1. clipboard_ARCH.exe needs to be installed somewhere accessible to windows - maybe %APPDATA%/clipboardy/ or something like that

    • how will this be installed?
      a) programmatically
      b) programmatically but with a special command (e.g. npm run install-fallback-exes [LOCATION])
      c) just tell people in the readme: if you want access to windows clipboard in WSL, download these exes, install into your PATH as 'clipboard.exe', then clipboardy will just look for clipboard.exe if its available when on WSL
    • if we are going to install programmatically, some tricks are needed to convert this path to something WSL understands (i.e. '/mnt/c/Users/USERNAME/AppData/...'). So get process.env['APPDATA'], parse it using require('path').win32 API, change 'C:' to '/mnt/c' or whatever drive letter it is, turn the whole thing into a posix path...
  2. need to tell clipboardy to use lib/windows.js when on WSL (since sys.platform === 'linux' it currently tries to use lib/linux.js)

    • (this is what I implemented in my closed PR and is a simple 1 liner using sindresorhus/is-wsl module)
  3. also need to tell lib/windows.js to look for those executables in the place we installed them earlier, or put that location on the PATH. It will not work if it just tries to run the executables in their current location wherever the node modules were installed.


IssueHunt Summary

g-rath g-rath has been rewarded.

Backers (Total: $36.00)

Submitted pull Requests


Tips


IssueHunt has been backed by the following sponsors. Become a sponsor

@issuehunt-oss
Copy link

issuehunt-oss bot commented Jan 21, 2020

@sindresorhus has funded $36.00 to this issue.


@issuehunt-oss issuehunt-oss bot added the 💵 Funded on Issuehunt This issue has been funded on Issuehunt label Jan 21, 2020
@rfgamaral
Copy link

rfgamaral commented Jan 21, 2020

The trick is, native windows binaries need to be on a letter drive to run (e.g. C: drive).

Are you sure about this? I just did some debugging on my WSL 1 instance (I don't have WSL2 for testing) and it works fine with a simple change:

1) Initialize a project like this:

/tmp
❯ mkdir clipboard
mkdir: created directory 'clipboard'

/tmp
❯ cd $_

/tmp/clipboard
❯ npm init --yes               
Wrote to /tmp/clipboard/package.json:

{
  "name": "clipboard",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}



/tmp/clipboard
❯ npm i --save clipboardy             
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

+ [email protected]
added 21 packages from 8 contributors and audited 24 packages in 2.721s
found 0 vulnerabilities

2) Add an index.js file with (for testing purposes):

const clipboardy = require('clipboardy');

clipboardy.writeSync('🦄');

3) Change linux in node_modules/clipboardy/index.js line 20 to windows (this is just for testing purposes, not production code).

4) Execute in your shell:

/tmp/clipboard
❯ node index.js

5) Paste (with Ctrl+V or something) into a Windows application and observe clipboardy working.

You can also test the pasting action and you'll see it also works just fine, try it.

I was going to tackle this issue on Issue Hunt but the fix feels quite simple and it's basically point 2 in the original post. I'm not the one who deserves it. Unless I'm missing something here? Perhaps this doesn't quite work on WSL 2?

@issuehunt-oss
Copy link

issuehunt-oss bot commented Feb 12, 2020

@sindresorhus has rewarded $32.40 to @g-rath. See it on IssueHunt

  • 💰 Total deposit: $36.00
  • 🎉 Repository reward(0%): $0.00
  • 🔧 Service fee(10%): $3.60

@issuehunt-oss issuehunt-oss bot added 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt and removed 💵 Funded on Issuehunt This issue has been funded on Issuehunt labels Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants