From owner-freebsd-current Sun Sep 17 20: 5:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by hub.freebsd.org (Postfix) with ESMTP id 3EB5437B422 for ; Sun, 17 Sep 2000 20:05:33 -0700 (PDT) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp (Exim 3.12 #7) id 13arFM-0001IU-00; Mon, 18 Sep 2000 03:05:32 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp4.email.verio.net with smtp (Exim 3.15 #4) id 13arFM-0005ih-00; Mon, 18 Sep 2000 03:05:32 +0000 From: "Tony Johnson" To: "Gerhard Sittig" , Subject: RE: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!) Date: Sun, 17 Sep 2000 22:05:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000917221759.B187@speedy.gsinet> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: > > > > > > [ ... 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