CompuServe Messages

>>If the user could specify an output file, could he then specify a pipe >>device? There are a couple or more Amiga pipe devices in the public domain. >>Maybe that would solve the appending problem. > >If it were only that simple! We could add the code to allow the user to >specify an output file in a day. That is no problem. The problem is that >we fire up C compiler, linkers, etc, and all do not appear to have this >capability (it must append, not just output). OTOH, maybe I've been >misinformed about AmigaDOS pipe devices all this time. If I can't control >every executable run by como.rexx, can this still be done? > I don't understand why you can't control every executable run by como.rexx. Maybe ARexx won't give you the control you need. I don't know. What kind of control do you mean? It seems to me that you would want a child process (the C compiler, linker, etc.) to inherit its standard I/O from its parent shell so that when it dies the next child can inherit the same standard I/O from the parent and just write to it (standard output or standard error). Are you fam- iliar with Mr. Fred Fish's freely redistributable Amiga disk library? I can usually find what I need pretty fast there, though new disks are added to the library so fast (about 100 to 150 per year, I think) that it's not always easy to find an up-to-date cataloging of it. I cannot overpraise this library. It is an ad hoc central clearinghouse for probably nearly all the worthwhile public domain, shareware, freeware, demoware, etc. software ever written for the Amiga. (And there certainly is an incredible amount of it.) Just about anything any programmer ever dreamed of doing with the Amiga has been done in one of these programs. Many include source code. Here are a couple of samples of software packages in the library (these are just examples, I'm not sure at all a pipe would work; after all, somehow you'd have to keep it open somehow, and then how could it be closed?): PipeDevice "A working 'pipe:' device, which allows the standard output of one process to be fed to the standard input of another process, with both processes running concurrently. Author: Matt Dillon" Disk #55. [More]