Making a gpg library

[raf]

David Champion wrote:

> 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.

users normally don't get confused when things work :)
or they might but aren't aware of it :)

> 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:

it's a more concise notation (and hence more convenient?)

> 	--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

yes, i'd prefer the --input-fd too because it's explicit.
user's shouldn't have to second-guess software (and vice versa).

the real problem would arise when a user on a system that doesn't
have a special /dev directory (e.g. mswin) creates a /dev directory
and a /dev/fd directory and ... and then wonders why gpg hangs
instead of reading the normal file /dev/fd/0 (contrived but possible).

raf