Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

Hi Jason,

I finally had some time to work on this. I made some good progress
initially – reading from and writing to the clipboard is easy and works
(based on my very limited testing so far).

However, I've run into the *effective* impossibility of being able to
reading, and saving, arbitrary data from the Windows clipboard. Other
software that does this actually *doesn't* do it – not in full generality.
For example, AutoHotkey, a popular Windows scripting tool, seems to support
specific formats and also *not *support other specific formats.

Just based on this basic failure, I started wondering about the convention
that Pass follows of even bothering to save the contents of the clipboard
before writing data to it. What's the source of that convention? Why did
you adopt it for Pass? Almost all other programs seem to just overwrite any
existing data – why does Pass try to retain the original contents?

I looked into the Cygwin */dev/clipboard* device and, probably more
importantly, tested it myself with clipboard data that I wasn't (easily)
able to save either – a JPG copied from the Google Chrome browser. Cygwin's
clipboard doesn't contain any data for the image!

So, given all of the above, is it sufficient that I can (easily) save and
restore *text* in the Windows clipboard? Or do we want to aim for all data?

Have you thought about how to handle the
Ubuntu-on-Windows-reports-that-it-is-a-version-of-Linux-and-one-from-the-future-too
problem? For now, for me just testing possible approaches, I'm working with
a *linux.sh* platform file.

Thanks,
Kenny

On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld <Jason at zx2c4.com>
wrote:

> Hi Kenny,
>
> Thanks for your response.
>
> > uname -r: 4.4.0-43-Microsoft
> > uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014
>
> Microsoft has evidently built a time machine and made a 4.4.0 before
> 4.4.0 existed! Surely if they can travel back in time, they can travel
> into the future too. In that case, I will stop working on this, and
> instead simply wait for them to bring pass compatibility back from a
> future timeline in which I actually do do the work. Wait, paradox.
>
> > uname -r: 4.4.0-43-Microsoft
>
> So this is really unfortunate. It means the only way we have of
> detecting WSL is by grepping uname -r. That seems like it won't mix
> nicely with the current strategy of source "$(uname)...". I'm a bit
> hesitant to bloat pass (even more) with non-standard Microsoft hacks,
> especially since Windows isn't free software, but I'll see if I can
> find a solution. If you have any suggestions, I'd be happy to hear
> them.
>
> > There's a (mildly disgusting) way to shove everything into the platform
> > file. PowerShell is installed by default on all versions of Windows since
> > Windows 7 and Windows Server 2008 R2 (both released at the end of 2009).
> > Given that WSL is new for Windows 10, it sure seems like supporting WSL
> > should imply we can safely expect PowerShell to be installed and
> available.
>
> Great, sounds like a plan then,
>
> Regards,
> Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20171122/4a436d22/attachment.html>