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

Kenny Evitt kenny.evitt at
Wed Apr 4 16:06:31 CEST 2018

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 –
Pass: The Standard Unix Password Manager for Bash on Ubuntu on Windows

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

On Thu, Jan 4, 2018 at 9:57 AM, Kenny Evitt <kenny.evitt at> 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>
> 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 **
>> platform file.
>> Thanks,
>> Kenny
>> On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld <Jason at>
>> 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: <>

More information about the Password-Store mailing list