<div dir="ltr">I've finished clipboard support for Bash on Ubuntu on Windows (BUW).<div><br></div><div>For now, I've setup a Git repo on GitHub with the changes – <a href="https://github.com/kenny-evitt/password-store-buw">kenny-evitt/password-store-buw: Pass: The Standard Unix Password Manager for Bash on Ubuntu on Windows</a></div><div><br></div><div>I still don't have any great ideas for the `uname` problem so the platform file for BUW is currently named *linux.sh*.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 9:57 AM, Kenny Evitt <span dir="ltr"><<a href="mailto:kenny.evitt@gmail.com" target="_blank">kenny.evitt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jason,<div><br></div><div>Happy New Year!</div><div><br></div><div>I'd like to continue working on adding clipboard support for Bash on Ubuntu on Windows (BUW).</div><div><br></div><div>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?</div><div><br></div><div>I haven't thought of or run across any nice workarounds for the problem of `uname` outputting "Linux" on BUW. Any thoughts?<br></div><div><br></div><div>Thanks,</div><div>Kenny</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 22, 2017 at 1:10 PM, Kenny Evitt <span dir="ltr"><<a href="mailto:kenny.evitt@gmail.com" target="_blank">kenny.evitt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jason,<div><br></div><div>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).</div><div><br></div><div>However, I've run into the *effective*<i> </i>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 <i>not </i>support other specific formats.</div><div><br></div><div>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?</div><div><br></div><div>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!</div><div><br></div><div>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?</div><div><br></div><div>Have you thought about how to handle the Ubuntu-on-Windows-reports-that<wbr>-it-is-a-version-of-Linux-and-<wbr>one-from-the-future-too problem? For now, for me just testing possible approaches, I'm working with a *linux.sh* platform file.</div><div><br></div><div>Thanks,</div><div>Kenny</div></div><div class="m_-5139109081897780732HOEnZb"><div class="m_-5139109081897780732h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kenny,<br>
<br>
Thanks for your response.<br>
<span><br>
> uname -r: 4.4.0-43-Microsoft<br>
> uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014<br>
<br>
</span>Microsoft has evidently built a time machine and made a 4.4.0 before<br>
4.4.0 existed! Surely if they can travel back in time, they can travel<br>
into the future too. In that case, I will stop working on this, and<br>
instead simply wait for them to bring pass compatibility back from a<br>
future timeline in which I actually do do the work. Wait, paradox.<br>
<br>
> uname -r: 4.4.0-43-Microsoft<br>
<br>
So this is really unfortunate. It means the only way we have of<br>
detecting WSL is by grepping uname -r. That seems like it won't mix<br>
nicely with the current strategy of source "$(uname)...". I'm a bit<br>
hesitant to bloat pass (even more) with non-standard Microsoft hacks,<br>
especially since Windows isn't free software, but I'll see if I can<br>
find a solution. If you have any suggestions, I'd be happy to hear<br>
them.<br>
<span><br>
> There's a (mildly disgusting) way to shove everything into the platform<br>
> file. PowerShell is installed by default on all versions of Windows since<br>
> Windows 7 and Windows Server 2008 R2 (both released at the end of 2009).<br>
> Given that WSL is new for Windows 10, it sure seems like supporting WSL<br>
> should imply we can safely expect PowerShell to be installed and available.<br>
<br>
</span>Great, sounds like a plan then,<br>
<br>
Regards,<br>
Jason<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>