What if programs could have any number of input and output file descriptors and the numbers/names along with their contents and data types were documented in the manual? Could eliminate the need to parse data altogether. I remember Common Lisp had something similar to this.
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
What you’re describing is similar to one of the more common ways that programs are run on mainframes by using Job Control Language (JCL).