Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!rutgers!mtune!mtunx!whuts!homxb!hropus!ki4pv!codas!usfvax2!jc3b21!fgd3 From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe) Newsgroups: comp.sys.amiga Subject: Re: Ban the Cloud! (plus sugg. for Workbench) Message-ID: <349@jc3b21.UUCP> Date: 24 Mar 88 04:56:32 GMT References: <318@jc3b21.UUCP> <761@sandino.quintus.UUCP> Organization: St. Petersburg Jr. College, FL Lines: 43 Keywords: Workbench Summary: summary In article <761@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > Output redirection: When a WB-started task produces output (to > stdout), a "magic window" is created. > Not bad. It seems complicated and I'm not sure how you solve the problem of knowing when a program wants to output to standard output but it might work. I don't like the idea of creating hidden files, though. Perhaps a logical device "StdOut:" could be assigned to RAM: and the files could be written there with a process ID number or some such. Of course, you might want you RAM for something else... Anyway, it's an appealing suggestion. > 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. > There is a difference between these commands: "pgm file1 file2 file3" and "pgm < file1" and "cat file1 file2 file3 | pgm" Your suggestion equates the first and third. I can think of times you might want to have a program open file1 for output and file2 and file3 for input. When you pass a group of files to the program through extended selection Workbench should cause the same thing happen as if you entered "pgm file1 file2 file3" on a CLI. You could open windows for stdin and stdout automatically and you could solve the output redirection problem by retaining the contents of the stdout window until it is closed or written to a file. But you still haven't solved the problem of redirection standard input, I don't think. > 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. You could write a new Workbench program along the lines of my suggestion without having to modify AmigaDOS at all. Since Workbench is just an application program sitting on top of AmigaDOS you could provide the new program as an alternative. The greatest difficulty I see it that the CLI and Workbench start programs differently. The program shouldn't know or care whether it was started from a CLI or from Workbench. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3