Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: cat -u Message-ID: <13266@ncoast.UUCP> Date: 17 Dec 88 18:09:10 GMT References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <8910@smoke.BRL.MIL> <8160@bloom-beacon.MIT.EDU> <146@minya.UUCP> <9138@smoke.BRL.MIL> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 37 As quoted from <9138@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn ): +--------------- | In a Macintosh-like environment, the situation is radically different, | because there is no good way to combine independent processes into a | larger unit. This frustrates the heck out of me when I'm using those | systems! In such an awful environment, so-called "integrated | applications" with maximal number of imbedded features are practically | required to get the job done. Of course, one useful integrated | application would be a UNIXy shell with pipes and a bunch of basic | UNIXy utilities. So much for the icon interface. +--------------- I still think this can be done; string lines between applications and/or documents (on a Mac, this might be done with, say, option-shift-doubleclick) and as each application is started in this manner, it opens a window into which one types any necessary commands (or use radio buttons, etc. as usual); the last one could be flagged by leaving off the shift or something, then after all commands are configured the pipeline is run. The advantage is that the pipeline can be made visible with lines (or even graphic pipelines!) between the icons of the applications. You could even run it in the background and check on its completeness by seeing when pipelines disappear from between icons! This is, of course, a first approximation. A real system should probably use the fact that a 2-d display allows one to trace multiple paths between programs, so one could (presumably) split a stream at one point, cause different actions to occur on each stream, then recombine them. Among other things. I also won't argue that the scheme outlines above is necessarily the best way to do it; it's just a possibility, and no doubt someone can come up with a better one. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@.