Fix issue that prevented freight-cache from working with GnuPG 2.x

[mattock]

URL: #72
Signed-off-by: Samuli Seppänen samuli@openvpn.net

[mmoll]

I'm unsure if this works that way generally, e.g. in a cronjob, could you test that?

[mattock]

Based on my testing this works properly even from cron. Not having it and cron reports the same failure as when testing manually. When this is present, freight-cache is happy, and cron is happy.

That said Travis seemed unhappy with not this being exported, so I will update this PR accordingly.

[mmoll]

I modified the code a bit to get shellcheck and BATS tests passing, could you please re-test?

[mattock]

@mmoll : the logic on/after line if GPG_TTY=$(tty) seems the exact opposite of what it should. As in: if GPG_TTY is set, then there's no need to export it. I tested this just in case an indeed the old problem is back.

[mmoll]

if GPG_TTY=$(tty) should only guard from aborting when tty fails. With the original code the BATS tests were broken, probably because the travis envrionment doesn't provide a working tty.

Im puzzeled, why it doesn't work as expected.

However, while testing in my env (debian 9 wityh systemd), I'm getting the following: If I'm exporting GPG_TTY in my shell directly, everything works, but when using freight-cache, even with the original one-liner fix, GPG_TTY is "not on a tty" and gpg fails again... which is bringing me back to the question of GH-72 if the whole siuation can really be work-arounded automatically...

[mattock]

@mmoll : by "when tty fails" you mean "the tty executable is not present/found" or "executable outputs an empty/unexpected string"?

[mattock]

I also had the "not a tty" problem earlier, but I'm no longer sure how to reproduce it.

[mmoll]

@mattock "tty fails" -> non-zero exit code