@schlichtanders please let me know if this works as expected for you

Thanks for your contribution! I don't think this is a good idea though. We don't want to add new features to the --encrypt / --decrypt / ... flags, but instead concentrate on the encrypt, decrypt, edit, ... subcommands (see also #1333).

I'm also not sure whether it's a good idea to add this to the encrypt and decrypt subcommands, it might be better to have separate subcommands for this, since the is sufficiently different from regular encryption/decryption (you don't need a specific filename, but rather an optional path; you always encrypt/decrypt in-place; etc.).

Thanks for your contribution! I don't think this is a good idea though. We don't want to add new features to the --encrypt / --decrypt / ... flags, but instead concentrate on the encrypt, decrypt, edit, ... subcommands (see also #1333).

I see, I have been wondering why there are two ways of executing actions, but #1333 explains everything.

I'm also not sure whether it's a good idea to add this to the encrypt and decrypt subcommands, it might be better to have separate subcommands for this, since the is sufficiently different from regular encryption/decryption (you don't need a specific filename, but rather an optional path; you always encrypt/decrypt in-place; etc.).

Personally, I am more in favor of a --recursive flag, because that seems analogous to the interface of other CLI tools. Currently, this change also works with modes like --rotate or --unset, so adding subcommands instead of a flag, would lead to a lot of duplication from my perspective.