> which the tool needs to do anyway

It doesn’t. The tool has no command-line arguments.

Please learn how the various shell concepts you’re referencing (like <()) actually work and get back to me if you still need to after that.

In any case, I’m well aware of the readability benefit of named arguments, and was when I made the original comment. So as you can imagine, I maintain that it’s a more than reasonable tradeoff, and I’ve covered the reasons for that. If you have nothing (correct) to add beyond hammering on this point, save it.

(nicer reply to this)

Yes, I’m aware of the readability benefit of named arguments, and made the original comment with that awareness too.

> Make a named pipe then. Shells have built-in primitives for that. I.e. <() and >() subshells in bash,

That’s /proc/self/fd again. But okay, you can make a named pipe to trade the procfs mount and corresponding open-for-read permission requirement for a named pipe open-for-write permission requirement without receiving the other benefits I listed of just passing a FD directly.

> I can't understand why you keep inflating the difficulty of simple commandline parsing

Not only have I not “kept inflating” this, I barely brought up the related concept of it being unnecessary complexity from an implementation side (which it is).

> which the tool needs to do anyway

It doesn’t. The tool has no command-line arguments.

> From interface perspective, how is `5>secretkey` simpler than `--sk secretkey`? The latter is descriptive, searchable and allows bash completion. I'll type `ed25519-keypair`, hit tab and recall what the argument called.

Not introducing More Than One Way To Do It after all (“Or have an option to read either a file descriptor or a file”) here is a good start, but it’s hard to beat passing a file descriptor for simplicity. If the program operates on a stream, the simplest interface passes the program a stream. (This program actually operates on something even simpler than a stream – a byte string – but Unix-likes, and shells especially, are terrible at passing those. And an FD isn’t just a stream, but the point is it’s closer.) A file path is another degree or more removed from that, and it’s up to the program if/how it’ll open that file path, or even how it’ll derive a file path from the string (does `-` mean stdin to this tool? does it write multiple files with different suffixes? what permissions does it set if the file is a new file – will it overwrite an existing file? is this parameter an input or an output?).

Your attached arguments seem to be about convenience during interactive use, rather than the kind of simplicity I was referring to. (Bonus minor point: tab completion is not necessarily any different.)

> Moreover, the simplest shell scripts that call this tool are unreadable (and thus unauditable) without the the manual.

That might be a stretch. But more importantly, who’s trying to audit use of these tools without the manual? You can be more sure of the program’s interpretation of `--sk secretkey` (well, maybe rather `--secret-key=./secretkey`) than `9>` if you know it runs successfully, but for anything beyond that, you do need to know how the program is intended to work.

Finally, something I probably should have mentioned earlier: it’s very easy to wrap the existing implementation in a shell function to give it a named-parameter filepath-based interface if you want, but the reverse is impossible.

No I picked the case I'm dealing with most commonly: which is establishing trust. X509 certs will also do this.

I have numerous criticisms of the GPG system but it's not a solution to just not implement any solution at all: I.e. I need revocation lists, I need intermediate keys, I need the ability to establish alternate chains of trust or promote a chain to trusted. Some of this is very hard to do with x509 even or not will supported.

Isn’t keybase to GPG what github is to git?

[flagged]