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

[Kenny Evitt]

Hi Jason,

Happy New Year!

I'd like to continue working on adding clipboard support for Bash on Ubuntu
on Windows (BUW).

I've got a working platform file that can both read from and write to the
clipboard. However, only text can be read and written. There's no way to
handle arbitrary data (e.g. an image file) on the clipboard on Windows. Is
that an issue?

I haven't thought of or run across any nice workarounds for the problem of
`uname` outputting "Linux" on BUW. Any thoughts?

Thanks,
Kenny

On Wed, Nov 22, 2017 at 1:10 PM, Kenny Evitt <kenny.evitt at gmail.com> wrote:

> 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/20180104/0c44b537/attachment.html>