Yes. Standard input and output are so ubiquitous shells were entirely designed around them with syntax that allows you to work with them implicity.
> There's nothing stopping a program from having more file descriptors passed in, and some programs do.
Can you please cite examples? I've never seen any software do that.
> There's no just no standard convention on how to do it.
Yeah. Such conventions would be nice. Perhaps a plan9 style virtual file system for all programs...
program/
input/
x
y
output/
x+y
x-yWell, almost no one actually says “input is read from fd 0 (stdin) and 4”, for example. Generally you say “input is read from file1 and file2”, and then the user can pass “/dev/fd/0 /dev/fd/4” as arguments. This copes better when the parent process doesn’t want to close any of its inherited file descriptors.
With `gpg --verify` you can specify which file descriptor you want it to output to. I've previously used it to ensure a file is verified by a key that is trusted ultimate. Something that otherwise requires outputting to a file.
Something like this:
tmpfifo="$(mktemp -u -t gpgverify.XXXXXXXXX)"
gpg --status-fd 3 --batch --verify "$sigFile" "$file" 3>"$tmpfifo"
grep -Eq '^\[GNUPG:] TRUST_(ULTIMATE|FULLY)' "$tmpfifo" || exit 1