BUG: can't use to_clipboard/read_clipboard on WSL 2.0

[mbkupfer]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

>>> pd.read_clipboard()
PyperclipException:
    Pyperclip could not find a copy/paste mechanism for your system.
    For more information, please visit
    https://pyperclip.readthedocs.io/en/latest/introduction.html#not-implemented-error

>>> pd.DataFrame().to_clipboard()
PyperclipException:
    Pyperclip could not find a copy/paste mechanism for your system.
    For more information, please visit
    https://pyperclip.readthedocs.io/en/latest/introduction.html#not-implemented-error

Problem description

pd.read_clipboard and pd.DataFrame.to_clipboard should work. For instance, I can run the following with no issues:

>>> import pyperclip
>>> pyperclip.copy('foo')
>>> pyperclip.paste()
'foo'

Expected Output

N/A

Output of pd.show_versions()

INSTALLED VERSIONS

commit : b5958ee
python : 3.8.5.final.0
python-bits : 64
OS : Linux
OS-release : 4.19.128-microsoft-standard
Version : #1 SMP Tue Jun 23 12:58:10 UTC 2020
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : C.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.1.5
numpy : 1.19.4
pytz : 2020.4
dateutil : 2.8.1
pip : 20.0.2
setuptools : 45.2.0
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.10.1
IPython : 7.19.0
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pytables : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[mbkupfer]

FWIW, I think the issue is here: https://github.com/pandas-dev/pandas/blob/master/pandas/io/clipboard/__init__.py#L523

Here is what I have in /proc/version: Note the microsoft is lower cased here and the python module is doing a case specific check.

$ cat /proc/version
Linux version 4.19.128-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Tue Jun 23 12:58:10 UTC 2020

[mbkupfer]

Ok, I can confirm that the if "Microsoft" in f.read(): is the offending line.

By switching to if "microsoft" in f.read(): (note the lower 'm'), it then worked for me! Please consider a patch for this.

[mroeschke]

Thanks for the investigation. Care to open a PR with that fix?

[mbkupfer]

Sure, although this is just my 3rd day of using WSL so I'm not certain what would be a universal fix. Comparing f.read().lower() would clearly fix it this time, but who knows how consistent proc/version is.

Perhaps a better option is to use an environment variable. It looks like the following are set for me:

WSLENV=WT_SESSION::WT_PROFILE_ID
WSL_DISTRO_NAME=Ubuntu-20.04
WSL_INTEROP=/run/WSL/10291_interop

Maybe we just use one of those? I'd lean towards WSL_DISTRO_NAME

[mbkupfer]

Upon further research, it looks like wslconfig has been there from the start. See: https://patrickwu.space/wslconf/#wsl-feature-availability

Maybe checking for that executable: wslconfig.exe would be the most compatible.