Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cs.columbia.edu!rmf From: rmf@cs.columbia.edu (Robert M. Fuhrer) Newsgroups: comp.sys.mac.misc Subject: Re: 7.0 CAN pipe (was Re: System 7.0 vs. NeXT Step) Message-ID: Date: 29 Jan 91 00:34:27 GMT References: <11468@helios.TAMU.EDU> <1991Jan23.204448.23778@unx2.ucc.okstate.edu> <5646@idunno.Princeton.EDU> <2898@casbah.acns.nwu.edu> <1991Jan25.092823.16868@cpsc.ucalgary.ca> <1991Jan28.2 Sender: news@cs.columbia.edu (The Daily News) Distribution: comp Organization: Columbia University Department of Computer Science Lines: 49 In-Reply-To: roy@phri.nyu.edu's message of 28 Jan 91 20:30:27 GMT I think an important point is being glossed over here. In Unix, pipes can be set up by users at the shell level because processes inherit their I/O connections/descriptors from the parent process. Thus, with the "standard input" and "standard output" channels being a well-known convention, a user can construct a pipeline of (almost) arbitrary programs *at the command shell level*. This doesn't require rewriting each program in the pipe to explicitly support pipes (as opposed to any other type of I/O source/sink). Of course, the Unix programs/tools for which it makes sense to place in a pipeline are typically simpler tools than those found in the Mac world. For instance, they typically are short on user interface. Off the top of my head, pseudo-visionary, and probably full of holes: At the same time, if I/O streams could somehow be "standardized," perhaps using a mechanism similar to the TYPE/CREATOR tags given to files, I could still envision redirecting the input/output streams of even applications with a GUI. To make this truly useful & general would probably entail defining a format for an action stream (a sort of command language, but I hesitate to imply a strong connection to something like MPW or CSH's command language) that would serve as directions for an application. So we'd have a "control stream" for telling the application what to do to its input(s) (e.g., print, perform a search/replace), an input stream which would serve as the "open document" for the application, and an output stream, to which the results of the control streams actions (the state of the document at the end?) would be pushed. The success of this clearly depends on the success of encapsulating a control stream's format. One simple (and probably insufficient) approach is to use a dummied-up event stream, perhaps from a "demonstrative" run of each program in the pipe (i.e., to demonstrate what is to be done). Naturally, for this to be any better than running each program in turn on temp files, you'd have to be able to capture the control stream for that program so as to use it in later invocations, or perhaps refer to it elsewhere in the pipe as appropriate. Well, anyway, enough said about nothing in particular. Comments everyone? -- -------------------------- Robert M. Fuhrer Computer Science Department Columbia University 1117B Fairchild Building Internet: rmf@cs.columbia.edu UUCP: ...!rutgers!cs.columbia.edu!rmf