Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds From: pds@quintus.UUCP (Peter Schachte) Newsgroups: comp.sys.amiga Subject: Re: Ban the Cloud! (plus sugg. for Workbench) Message-ID: <832@sandino.quintus.UUCP> Date: 29 Mar 88 01:13:41 GMT References: <318@jc3b21.UUCP> <349@jc3b21.UUCP> Organization: Quintus Computer Systems, Mountain View, CA Lines: 90 Keywords: Workbench In article <349@jc3b21.UUCP>, fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > 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. Do you mean complicated to the user, or complicated to implement. The attraction to me is that it seems simpler than pipes and redirection in unix, but seems (almost) as powerful. The way you work it is that when the program starts up, you create and pass it a special output stream which is defined so that any call to Write() on that stream creates the window, does all the necessary magic, and then patches up the stream (file descriptor) to make subsequent writes write into the temporary file. I think this could be done with a MAGIC: device (gurus correct me if I'm wrong; I've never written a device). > I don't like the idea of creating hidden files, though. The reason I want the file to be hidden is that I want it to go away cleanly unless the user does something with it explicitly. This is important to my model of how it will be used. The idea is that these magic windows represent (present) the output of a task. This data could be put into a file (redirection), or sent to another task (piping). But whatever I do, nothing I don't know about and haven't asked for will be left around when I close the window. Maybe I've misunderstood you. I did expect that the data would be stored in some ordinary file somewhere. The MAGIC: thing is just a way to make sure that a window views the file, and the file is deleted when the window is closed. That's all. The file isn't "hidden" from the OS. > > 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. Sort of. Actually, I didn't address the idea of arguments to programs started from the WB at all. Remember, not all command line arguments are files. Switches, text strings, etc., must be handled, too. I'm afraid I don't see any way to do this automatically for programs that didn't anticipate being used from the WB. Ideally, there would be a way to specify what arguments the program takes, and the super-WB would use this to prompt users for this info in some simple, consistent, and non-troublesome way. And at this level, you could specify a file by pointing to an icon. Any proposals for such a thing? > ... you could > solve the output redirection problem by retaining the contents of the > stdout window until it is closed or written to a file. I guess I did misunderstand you, because this is just what I meant. > But you still > haven't solved the problem of redirection standard input, I don't think. I think I have. What I haven't solved is the problem of command line arguments. > You could write a new Workbench program along the lines of my suggestion > without having to modify AmigaDOS at all. Whatever you do, I think you would have to at least modify WB. I'd hate to have to write it again. Perhaps there would be some way to patch it to set up stdin and stdout as I suggest (and do whatever we decide to do about command line args) before exec'ing the program. I now believe it wouldn't be necessary to do anything to the exec lib. > The program shouldn't know or > care whether it was started from a CLI or from Workbench. Agreed, almost. I think the tool types of the WB are a very useful facility (which should be extended). I wouldn't want them to go away. I also do believe that any program should be able to be started from either a command line or the WB, and that the program shouldn't know whether which. Therefore, I'd like all programs (in fact, all files) to have this sort of information (tool types) associated with them. Given this, I agree whole-heartedly. I do believe this could well be along an expansion path from where we are now without breaking old programs. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds