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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 >>> >> >> >
_______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
