Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!pds From: pds@quintus.UUCP (Peter Schachte) Newsgroups: comp.sys.amiga Subject: Re: Ban the Cloud! (plus sugg. for Workbench) Message-ID: <761@sandino.quintus.UUCP> Date: 11 Mar 88 20:54:37 GMT References: <318@jc3b21.UUCP> <3624@bloom-beacon.MIT.EDU> Organization: Quintus Computer Systems, Mountain View, CA Lines: 59 Keywords: Workbench Summary: How about "magic windows" to handle redirection? In article <3624@bloom-beacon.MIT.EDU>, cthulhu@athena.mit.edu (Jim Reich) writes: > In article <329@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > >(4) Workbench doesn't have the CLI's provisions for I/O redirection. > >How about two special icons on the Workbench screen: "<" and ">". > >... Drop a file on one and I/O is redirected to or from that file. > Bad bad bad. Each program should be allowed to have its own > output or input redirected from/to different sources. It would > be nice to have a sort of bin to dump a file into so that it would go to > standard output or input though. Perhaps it would be used as standard input > for the active window? Any ideas, anyone? How about pipes? Tricky. How about this: Output redirection: When a WB-started task produces output (to stdout), a "magic window" is created. This window displays a scrolling view of the output of the task. You see the output as it comes out, and can scroll it at will. There would be a hidden file behind the window. The title bar would reflect which WB tool produced the stuff in the window, and would indicate when the task was complete. The user could then close the window (implicitly deleting the hidden file), or, say through a menu, create an ordinary (permanent, named) file. That way you don't need to decide whether to "redirect" the output of a task until after you see it. Input redirection: The files you select (while holding the shift key) before firing the WB tool are implicitly cat'd and sent to stdin of the task. No problem. Also, you should be able to select a "magic window" for input to a tool in the same way. Pipes: For starters, if you can select a "magic window" for input to a tool before the task that is generating it is finished, you have a kind of pipe. Also, you could close a "magic window" after feeding it to the stdin of a tool, and the bytes would still go from stdout of one task to stdin of the other, but you wouldn't see them. Not closing the window gives you a sort of unix tee. Shell scripts: It would be good if there were some way to create a new tool by composing existing tools, but I can't a way offhand. What's really needed is an iconic programming language, sort of a csh (or sh) that you program by moving and copying icons around. This starts getting hard, and I don't have any ideas on this. Implementation: Not too terribly hard. you have to modify AmigaDOS Write() to understand a new kind of file control block: one that represents an unopened output stream. This fcb (what is the AmigaDOS name for this, anyway?) would be created when WB started up a tool (so WB would have to be patched, too. Not sure how to do this. Anyone?). When Write() got the first request to send a bufferful to one of this fcbs, a file would be created in some temporary place (T:? remember this output may get big!), and a new task would be started to open the magic window and handed a read-only lock on the file. Not too bad, eh? With a good implementation, this could be powerful enough to make many uses of a CLI unnecessary. And with a scripting language and some sort of history mechanism, (and a lot of the other recommendations people have made here), it ought to be able to replace MOST uses of a CLI.-- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds