[pass] pass grep doesn't spawn pinentry dialog when no cached password is available in gpg-agent

[Allan Odgaard]

On 28 Nov 2014, at 7:40, Lucas Hoffmann wrote:

>> There is a similar problem on OS X, here though no output is shown, 
>> instead
>> a background task takes 100% CPU time.

An update on my previous report, I now see this outout (for each 
password store entry):

	gpg: cancelled by user
	gpg: decryption failed: No secret key

Possibly this has changed after upgrading gpg2.

> […] This reports that stdin and stderr are connected to the 
> terminal.

But you didn’t change stdout to a pipe. This will report that we do 
not have a tty (connected to stdout):

	{ test -t 1 || echo stdout is not a tty; }|cat

> The fact that stdout is not connected should not be a problem

Sorry, my reply was a hasty recollection of some previous analysis I did 
long ago.

The issue is with stdin (not stdout), so it’s not the pipe connecting 
$GPG to grep but rather the pipe that connects “read” used in the 
loop with find.

This is the loop in question:

	while read -r -d "" passfile; do
		…
	done < <(find -L "$PREFIX" -iname '*.gpg' -print0)

Everything inside this loop is disconnected from the tty because stdin 
has been redirected to a pipe.

It’s a non-trival loop body, otherwise I would have said to just 
rewrite it using xargs.