Speedup pass on macOS and brew

[Allan Odgaard]

On 23 Oct 2018, at 20:01, pass-maillinglist at artursterz.de wrote:

>> Also, if it is desirable with additional fault tolerance, I would 
>> argue it belongs in a different commit, as it’s unrelated to the 
>> optimization that is being proposed.
> I guess having a version that is reasonably fast and fault tolerant at 
> the same time would be great.

This is just my personal opinion, but one commit should do only one 
thing.

Say the extra checks break it for MacPort users, so someone may decide 
to revert the commit because it was faulty, but then we also lose the 
homebrew optimization, even though that part worked fine.

> I pasted a fourth version below, which tries to handle the case, that 
> brew is available, but gnu-getopt was not installed using brew. I also 
> implemented the test for macports, but again since I am not using 
> macports, I can not test this.
>
> What do you think?

Since we are moving away from testing “does the user have `brew`? OK, 
assume they installed `getopt`” to testing whether `getopt` actually 
exists in a set of likely directories, I suggest the code be rewritten 
to use this approach:

	for prefix in "$(brew --prefix 2>/dev/null)/opt/gnu-getopt" /opt/local 
/usr/local; do
		GETOPT="${prefix}/bin/getopt"
		test -x "$GETOPT" && break
	done

We could add a final check (after the loop) to see if `GETOPT` is 
executable, but an error should be thrown regardless, it will just be at 
a later time.

The only thing that annoys me with the code above is that we always 
execute `brew`, though technically the overhead is the same or less than 
guarding it with a `command -v brew` statement (less for people who have 
the executable).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20181023/1769d6c0/attachment-0001.html>