> > How about just doing something like `EDITOR=magic.sh pass edit`, where > magic.sh is a shell script that uses sed(1) to modify the password? >
Worked. Pushed. Von On Sat, Apr 19, 2014 at 2:13 PM, Von Welch <[email protected]> wrote: > Hi Lukas, > > On Sat, Apr 19, 2014 at 1:52 PM, Lukas Fleischer <[email protected]> > wrote: > > > 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? >> > >> >> Sounds good to me. However, the current Makefile adds a reference to >> "/usr/lib/password-store.platform.sh" (shouldn't that rather be >> "/usr/lib/password-store/platform.sh"?) to the shell script. So simply >> splitting the Makefile target won't work. >> > > You are right. It's only working for me because I previously installed > pass. (I would assume you are also right about the typo.) > > >> What I suggest is: >> >> * Rename password-store.sh to password-store.sh.in. >> >> * Use m4 (or some other tool) to inline the correct platform-specific >> code into password-store.sh.in and save the modified file as >> password-store.sh when running `make`. >> >> * Just install(1) the files when running `make install`. >> > > Sounds reasonable to me. > > I think what I have is good enough to let me test and I'll see if someone > else wants to take on rebuilding the make system. > > >> > 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. >> > >> >> What about `echo $secret | pass insert -e $pw`? Doesn't that work? >> > > Ah, I missed '-e' turns off confirmation. > > Hmm, it does work, but for some reason returns a non-zero exit status. > Some minor bug I assume. > > >> > 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. >> > >> >> How about just doing something like `EDITOR=magic.sh pass edit`, where >> magic.sh is a shell script that uses sed(1) to modify the password? >> > > Good idea. I'll give it a try. > > Thanks, > > Von > > > On Sat, Apr 19, 2014 at 1:52 PM, Lukas Fleischer <[email protected]>wrote: > >> On Sat, 19 Apr 2014 at 18:56:34, Von Welch wrote: >> > Jason, all, >> > >> > I've added a few more tests, enough to to find a few more issues. I'm >> going >> > to pause at this point and wait for feedback to see if we agree this is >> the >> > right path before doing more. The basic approach seems solid to me with >> a >> > few small issues/questions to resolve: >> > >> > 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? >> > >> >> I would say it is fine to use an unencrypted key -- at least for the >> very basic tests. >> >> > 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? >> > >> >> Sounds good to me. However, the current Makefile adds a reference to >> "/usr/lib/password-store.platform.sh" (shouldn't that rather be >> "/usr/lib/password-store/platform.sh"?) to the shell script. So simply >> splitting the Makefile target won't work. >> >> What I suggest is: >> >> * Rename password-store.sh to password-store.sh.in. >> >> * Use m4 (or some other tool) to inline the correct platform-specific >> code into password-store.sh.in and save the modified file as >> password-store.sh when running `make`. >> >> * Just install(1) the files when running `make install`. >> >> > 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. >> > >> >> What about `echo $secret | pass insert -e $pw`? Doesn't that work? >> >> > 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. >> > >> >> How about just doing something like `EDITOR=magic.sh pass edit`, where >> magic.sh is a shell script that uses sed(1) to modify the password? >> >> > Von >> > [...] >> > > > >
_______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
