Date: Sun, 17 Sep 2000 22:05:31 -0500 From: "Tony Johnson" <gjohnson@gs.verio.net> To: "Gerhard Sittig" <Gerhard.Sittig@gmx.net>, <current@FreeBSD.ORG> Subject: RE: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!) Message-ID: <FOENIGAJAKGPLNGHHADIEEJCCOAA.gjohnson@gs.verio.net> In-Reply-To: <20000917221759.B187@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
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: owner-freebsd-current@FreeBSD.ORG
[mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Gerhard Sittig
Sent: Sunday, September 17, 2000 3:18 PM
To: current@FreeBSD.ORG
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("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" Gerhard.Sittig@gmx.net
--
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FOENIGAJAKGPLNGHHADIEEJCCOAA.gjohnson>