I implemented that but then I found this in the man page:

  This command differs from the default operation, as it never writes
  to the filename which is included in the file and it rejects files
  that don't begin with an encrypted message.

Thus decryption is the default operation. The problem is that the
code also tries to do other things if it does not find encrypted data.
Note that the "never writes to the filename which is included in the
file" is wrong because gpg does not do that by default.

Also note that the key listing is different from a real key listing and in
effect more like an improved --list-packets. Maybe we should make a hard break
and only do encryption without an command - at least when --batch or
--with-colons is given.

Right, agreed -- there is no way to get to the "improved --list-packets" without
using the dubious approach of not specifying a command at all.

I agree that a hard failure when --batch is given without an explicit command
would be reasonable (though that means we will be effectively breaking
python-gnupg and others like it, which do try to use it). I'm not sure i
understand the reasoning behind a hard failure for --with-colons without an
explicit command.

I meant decryption. My idea is:

1. In attended mode: Just print a warning message.
2. In unattended mode (--batch or --with-colons): Make --decrypt the default

and do not print a warning message. That would be a hardfailure for everything
but encrypted data

The idea is that attended command line use keeps on working but using it in
scripts (--batch, etc) will hard failure.

make the default operation --decrypt

I'll just note that the only programmatic unattended uses i've seen have been
*not* decryption. they're attempts to list a keyring. So switching to
decrypted mode there will provide the same amount of breakage as requiring an
explicit command, but without the benefit of requiring explicit intent.

Any variation in behavior between automated and "attended" use is a debugging
pain point that actually seems to create work in the rest of the ecosystem. The
more GnuPG can keep its rules and behavior simple to understand, the better.

Frankly I am used to leave out the -d to use the default. I have seen the -d in
action only in CitizenFour ;-)

Need to think again about this.

(The last line in T2943 (wk on Feb 13 2017, 07:22 PM / Roundup) was garbage)

I looked around a bit and found many places where the decryption was given as the default operation for gpg and thus requiring -d would break a lot of tutorial. Of course we could educate the user in attended mode that "-d" is now required but I fear that this will break too many scripts.

So what about this:

• • Add a new command which does what the current default keylisting does right now. This could actually be "--dry-run --import-options import-show --import" to give a proper listing of the data in the file. Any suggestion for a name?
• Add a backward compatibility option to switch back to the ugly old way.

Those scripts are likely already broken if their input happens to be different than what they expect, so i don't much care about "breaking" them. That said, it sounds like you're suggesting that the default mode will just be "--decrypt" and we'll let people continue using it that way.

I think "--dry-run --import-options import-show --import" sounds like a reasonable constellation of options that describes the current non-decrypt default. Does it need an extra name?

I don't think a backward-compatibility option makes sense -- does it? if someone can edit their script to add a backward-compatibility option to their script, they can add the correct "forward-compatibility" option or command arguments.