On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
> <crazy mode on>
>
> How much sense does it make to think about implementing tee and
> select methods this way? Like "open file1 and file2 and write to
> both of them whatever I give to you" and "give me data coming in
> from whatever file is in this set"? The only problem is to
> determine available characters to separate these names. '+' as
> well as ':', ',' and ';' are perfectly valid characters for
> constructing filenames. '&' seems to be too, but could be used
> rarely enough. And the split upon these new separators actually
> should be done only when the appropriate SDO_ flags are passed.
>
> e.g.
> superduperopen("file1&file2", "a+", SDO_TEEFILES)
> superduperopen("file1&file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
[snip]
> parameters) have to pass certain checks. Nobody should try to
> read from "|command". And I cannot see any use for "write to
> whatever descriptor is ready to write to first" as would result
> from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That feature
should be in there too :)
I do see a use to "write to whatever descriptor is ready first". It
could be used for a very simple multithreading-like implementation.
Spawn 8 child processes, attach them to one stream with
superduperopen(), and pass single-byte commands to one that is waiting
to handle one. If all 8 are busy, you block, or return something like
EAGAIN. This description is very pseudo-something, btw :)
> Feel free to correct the flag's data type. I have the feeling
> not all int's have 32bits. :) Some other means of storage might
int works for open, I doubt whether we need more options than open does :)
> be more appropriate while still being easy to combine and to pass
> to the function. But I feel strings like "STD,PIPE,TEE" are
There's no reason for that. We have a compiler that can parse *unquoted*
strings like STD | PIPE | TEE and create single int's out of that. Ain't
it wonderful :)
> harder to parse and single character notation like the "wt" mode
> flags are harder to find (think of) and to read (in terms of
> eyeballing the source code) for the sdo case.
I do think the "w+" 'n stuff notation in popen sucks. This is our chance
to turn those into bitflags too, for superduperopen anyway.
Greetz, Peter
--
dataloss networks
'/ignore-ance is bliss' - me
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message