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

[Kenny Evitt]

I've finished clipboard support for Bash on Ubuntu on Windows (BUW).

For now, I've setup a Git repo on GitHub with the changes –
kenny-evitt/password-store-buw:
Pass: The Standard Unix Password Manager for Bash on Ubuntu on Windows
<https://github.com/kenny-evitt/password-store-buw>

I still don't have any great ideas for the `uname` problem so the platform
file for BUW is currently named *linux.sh*.

On Thu, Jan 4, 2018 at 9:57 AM, Kenny Evitt <kenny.evitt at gmail.com> wrote:

> 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/20180404/4da6d16f/attachment.html>