Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
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("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "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
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
[ ... how to find separating chars not used in filenames ... ]
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
Of course it would be the cleanest thing to do, and I was aware
of this possibility. But that's when the interface is _very_
much different from fopen(3). That's where I'm reluctant to
introduce this hard a change. :) In addition it was not quite
clear how appropriate this semantics would be, at all.
Unless one sees this (yet to be renamed accordingly:) function as
something very different from fopen and "easy adaption of
existing utilities" is not so much of a concern, I still hesitate
to put this much more burdon on the programmer: opening single
files like fopen(3) did before would now mean to handle a "list
of one filenames" instead of passing whatever was there before --
just to have the lib handle stdin recognition.
I could suggest something even more ugly than the above "xy" for
those who want easy adaption:
superduperopen(char *fn, char *mode, int flags, ...);
with the \dots being zero or more filenames, only evaluated when
the flags suggest to do so. But it tears the first and any other
filename apart. The other solution was to provide two functions:
one fopen like plus the flags for when only one filename is
needed and another with a filename list, mode, and flags; being
the first a wrapper for the second (much as IPC::Open2 and
IPC::Open3 are). This would allow for a simple fixsized two
element array handled in the wrapper without the app's need to
care about anything more but the SDO_ flags for STD in the
existing cases we mainly talk about (cat(1) and the like).
After all I'm still not sure how useful this kind of extension
would be. It all started out with the wish for knowing "-" and
"|cmd" / "cmd|" where an interface like
superduperopen(char *fn, char *mode, int flags);
is sufficient.
[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 :)
That's obvious (isn't it?). But there are definitely
combinations which aren't really useful. And some even shouldn't
be allowed at all.
Which brings me to a completely different topic: How much sense
does it make being able to read(2) directories? Shouldn't be
other functions (like stat, chdir, opendir friends) sufficient
and shouldn't read fail with EISDIR or something similar? I've
been bitten quite often from the garbled output of "head *" with
damaged terminal fonts afterwards. I know Linux had this before
but has been fixed for several years now. I'm aware this could
be a religious topic, but I feel it should have been discussed
before. It's just that I think searching for "read" or
"directory" in the list's archive is not very useful. Where can
I find more information on the reasons to still allow for this
misfeature (it's how I judge this short of knowing any
advantages).
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.
Yes, but the same restriction as to "read from whatever is ready
first" apply: The type of data has to be "fixed size and without
problems splittable" or "not really produced in parallel but more
alternatively" as one byte commands are or keystrokes could be.
That's where I see only limited use for these. It heavily
depends on the applications' environments.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
I think this thread needs to be killed. Whipping a horse that was dead 3
days ago is way too much. People have expressed thier opposition to PHK's
post and so it should end there.
For the love of cgi scripts, please keep /dev/stdin out so that peoples
web work can be sent to from the masses.
This is posted on NetBSD's web page, "Solutions and not hacks"
Stop trying to hack up a broken idea in order to kinda-sorta make it work
and produce a "Solution"
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gerhard Sittig
Sent: Sunday, September 17, 2000 3:18 PM
To: [EMAIL PROTECTED]
Subject: Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs
near you!)
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
[ ... how to find separating chars not used in filenames ... ]
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
Of course it would be the cleanest thing to do, and I was aware
of this possibility. But that's when the interface is _very_
much different from fopen(3). That's where I'm reluctant to
introduce this hard a change. :) In addition it was not quite
clear how appropriate this semantics would be, at all.
Unless one sees this (yet to be renamed accordingly:) function as
something very different from fopen and "easy adaption of
existing utilities" is not so much of a concern, I still hesitate
to put this much more burdon on the programmer: opening single
files like fopen(3) did before would now mean to handle a "list
of one filenames" instead of passing whatever was there before --
just to have the lib handle stdin recognition.
I could suggest something even more ugly than the above "xy" for
those who want easy adaption:
superduperopen(char *fn, char *mode, int flags, ...);
with the \dots being zero or more filenames, only evaluated when
the flags suggest to do so. But it tears the first and any other
filename apart. The other solution was to provide two functions:
one fopen like plus the flags for when only one filename is
needed and another with a filename list, mode, and flags; being
the first a wrapper for the second (much as IPC::Open2 and
IPC::Open3 are). This would allow for a simple fixsized two
element array handled in the wrapper without the app's need to
care about anything more but the SDO_ flags for STD in the
existing cases we mainly talk about (cat(1) and the like).
After all I'm still not sure how useful this kind of extension
would be. It all started out with the wish for knowing "-" and
"|cmd" / "cmd|" where an interface like
superduperopen(char *fn, char *mode, int flags);
is sufficient.
[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 :)
That's obvious (isn't it?). But there are definitely
combinations which aren't really useful. And some even shouldn't
be allowed at all.
Which brings me to a completely different topic: How much sense
does it make being able to read(2) directories? Shouldn't be
other functions (like stat, chdir, opendir friends) sufficient
and shouldn't read fail with EISDIR or something similar? I've
been bitten quite often from the garbled output of "head *" with
damaged terminal fonts afterwards. I know Linux had this before
but has been fixed for several years now. I'm aware this could
be a religious topic, but I feel it should have been discussed
before. It's just that I think searching for "read" or
"directory" in the list's archive is not very useful. Where can
I find more information on the reasons to still allow for this
misfeature (it's how I judge this short of knowing any
advantages).
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.
Yes, but the same restriction as to "read from whatever is ready
first" apply: The type of data has to be "fixed size and without
problems splittable" or "not really produced in parallel but more
alternatively" as one byte commands are or keystrokes could be.
That's where I see only limited use for these. It heavily
depends on the applications' environments.
virtually yours 82D1
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
using Brian's post since I don't have the original around ...
On Sat, Sep 16, 2000 at 03:49 +0100, Brian Somers wrote:
[ attribution missing, is it Poul-Henning Kamp's text? ]
The majority of these programs could be handled by adding
knowledge of "-" as a magic filename to fopen(3).
[.]
At the same time I would really love if we implemented "|.*"
to mean "do an popen(3)" instead.
The only reasonable way to provide this functionality to apps not
wanting to reinvent it themselves without breaking those who feel
that files should be just that - files - is a _new_ function next
to fopen(3) named some rather alerting way like superduperopen(3)
with flags like SDO_KNOWS_STDIN, SDO_CAN_PIPEFROM,
SDO_CAN_PIPEINTO and whatever other extension you can think of.
32 of these new behaviour patterns should suffice for quite a
while. :)
This will collapse the "-" recognition and handling logic in
existing programs to passing a simple flag to a different
function (with only one more int parameter compared to fopen(3))
and leave those alone who just want to fopen(3) any file. And
when the options set is extended no app will "inherit" unwanted
and unexpected features turning out to be holes. Unless there's
a SDO_DO_ANY_PRESENT_AND_FUTURE_MAGIC flag passed with a value of
0x. But authors doing so will get what they deserve. :
One could even think of switching to the new function "to be
ready" and passing a SDO_DONT_DO_ANY_MAGIC flag.
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("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
Semantics could be braindead simple: TEE will just dup any data
to every file specified and SELECT will have implicit priorities
since there's no logic doing round robing or something. This
will suffice for randomly filled input channels being fed more
alternatively rather than concurrently.
crazy mode off
Of course the mode parameter from fopen(3) and the magicmask
parameter from superduperopen(3) (i.e. the second and third
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.
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
be more appropriate while still being easy to combine and to pass
to the function. But I feel strings like "STD,PIPE,TEE" are
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.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
