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("file1&file2", "a+", SDO_TEEFILES)
> > superduperopen("file1&file2", "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 "x&y" 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
