<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 19, 2014 at 6:56 PM, Von Welch <span dir="ltr"><<a href="mailto:von@vwelch.com" target="_blank">von@vwelch.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>1) Unencrypted GPG key vs GPG-agent. Except for some weirdness with 'pass init' with an unencrypted gpg key and a closed stdin, an unencrypted key seems to work well. It seems simpler than getting a gpg-agent running. Acceptable or do we really want to use an agent for testing?</div>
</div></blockquote><div><br></div><div>I suspect it's okay to not use an agent for testing, but I'll investigate in more detail when I'm home on tuesday.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">

<div><br></div><div>2) "Building" pass. I figured out I really needed a version of the pass script to test with that has the platform-specific stuff replaced. Currently 'make install' is the only way to create a fully-functional pass script, but I don't want to require installation for testing. Hence in my branch I split the 'make install' process into 'make' which creates the platform-specific script and 'make install' which installs it. This lets you run 'make && make tests' without an install (actually 'make tests' will do a 'make' if needed, but you get the idea.) Sound reasonable?</div>
</div></blockquote><div><br></div><div>I'm not okay with your solution. I've implemented a viable workaround for the issue here:</div><div><br></div><div><a href="http://git.zx2c4.com/password-store/commit/?id=78098bab96c0228d700978492152ba3c2a872d2b">http://git.zx2c4.com/password-store/commit/?id=78098bab96c0228d700978492152ba3c2a872d2b</a><br>
</div><div><br></div><div>Simply call src/password-store.sh, and set PASSWORD_STORE_PLATFORM_FILE="$(dirname "$0")/platform/$(uname | cut -d _ -f 1 | tr '[:upper:]' '[:lower:]').sh" inside the test harness. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">

<div><br></div><div>3) 'pass insert' requires interactivity. It insists on asking for the password twice even if stdin is not a terminal (a pipe). We'll either need to change that behavior, find some clever way of working around it for testing, or just decide it's not part of the test suite.</div>
</div></blockquote><div><br></div><div>See the -e option and the -m option.</div><div>There should be tests for all combinations of options.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>4) Going further with regards to interactivity, I have no idea how to test 'pass edit' at this point. I guess one could create a vimscript or something similar to simulate a user typing? Or just not worry about it for the test suite.</div>
</div></blockquote><div><br></div><div>EDITOR=somescript.sh</div><div><br></div><div>somescript.sh:</div><div>  exec sed -i 's/adsafasdf/asdfadsf/' "$1"</div></div></div></div>