Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works

[gnupg at raf.org]

Hi,

I've just upgraded a debian8 host to debian9
and got the new gpg (v2.1.18) and now my cronjob
that encrypts data no longer works because it wants
input for some reason.

The gpg command is something like:

  cmd... | gpg --default-recipient-self --encrypt --output filename.gpg

At first, it said (via cron):

  gpg: cannot open '/dev/tty': No such device or address

Then I stupidly added --no-tty and it said:

  gpg: Sorry, no terminal at all requested - can't get input

So it really wants input all of a sudden.

So I ran it manually and it turned out that --default-recipient-self
no longer works:

  You did not specify a user ID. (you may use "-r")

  Current recipients:

  Enter the user ID.  End with an empty line: 

Any idea why it no longer knows who the default recipient is?
There's only one key that it could be.

The documentation for --default-recipient-self says:

  The default key is the first one from the secret keyring or
  the one set with --default-key.

But it's not finding it:

  $ gpg --list-keys
  /home/user/.gnupg/pubring.gpg
  -----------------------------
  pub   rsa2048 2016-05-15 [SC]
        EB2040CBE8E339FD1210B004FB2608650E6E1961
  uid           [ultimate] Name <name at domain.com>
  sub   rsa2048 2016-05-15 [E]

  $ gpg --list-secret-keys
  /home/user/.gnupg/pubring.gpg
  -----------------------------
  sec   rsa2048 2016-05-15 [SC]
        EB2040CBE8E339FD1210B004FB2608650E6E1961
  uid           [ultimate] Name <name at domain.com>
  ssb   rsa2048 2016-05-15 [E]

I can specify the ID explicitly (i.e. name at domain.com) and
then it works but I shouldn't have to, should I?

Why can it find the key when I name it but it can't find
it by itself?

Thanks for any insight.

cheers,
raf

P.S. I noticed a couple of possible gpg(1) man page errors.

(1) The documentation for --default-key says:

  Use name as the default key to sign with.

But the documentation for --default-recipient-self
implies that it is also for encryption, not just signing.

Unless --recipient and --default-recipient apply to encryption
but --default-recipient-self only applies to signing.
If so, that would be confusing and should probably be stated
explicitly.

(2) The documentation for --no-tty says:

  Make sure that the TTY (terminal) is never used for any output...

But it also makes sure that the TTY is not used for input as well.