Making a gpg library

[David Champion]

On 2000.10.25, in <20001026111448.B5233 at comdyn.com.au>,
	"raf" <raf at comdyn.com.au> wrote:
> 
> but wouldn't it just work? i.e. gpg doesn't recognise it as /dev/fd/*
> (because it isn't) so it just does the normal thing of opening the
> "file" /dev/fds/* instead which is the file descriptor.

It would work, but I think that it would confuse the less-informed
user.  How would this be documented?  Consider two cases:

	1. "Alphix" has no /dev/fd-like tree.  The Alphix user must
	   thus be told that, to read a string from fd 4, he must
	   specify /dev/fd/4 as a path (even though it doesn't exist).
	   OK, not so bad.

	2. "Betux" places file descriptor pseudo-files in /dev/fds.
	   The Betux user reads the same documentation, sees that she
	   should write /dev/fd/4.  That doesn't exist, and /dev/fds/4
	   does.  Either will work, but what is going on here?  This is
	   a mite confusing, I think, even though it's basically
	   functional.

I'm not sure what the significant advantage of using /dev/fd/N over
implementing --input-fd is.  You can even call it --input-file instead,
and, as in Werner's previous thought, put it to double duty:

	--input-file 4			Read from "./4"
	--input-file #4			Read from fd #4

... or something like that.  Of course, in this case one doesn't need
--input-file, but it makes the syntax clearer when the file path serves
two functions.

-- 
 -D.	dgc at uchicago.edu	NSIT	University of Chicago