david@bdt.UUCP (David Beckemeyer) (02/02/90)
In article <2006@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >Yes, Fdup / Fforce will gag when you get too deep, but Hblank is not >the answer. If you want to link programs with temporary files, great! >Add command-line options to each program in the chain which say, "Use >this file for input, that one for output." I had hoped that J.Bammi >could win you over to this point of view. Or you could just use MICRO RTX which has working Fdup / Force as well as Popen (pipe popen) so you don't even need to use temporary files. For example: int pfd[2]; int sav0; sav0 = Fdup(0); /* save stdin */ Popen(pfd); /* create pipe */ Fforce(0, pfd[0]); /* force child to read pipe as stdin */ Pexec(100, "child.prg", tail, env); /* start child (fork) */ Fforce(0, sav0); /* restore stdin (child is running now) */ Fclose(sav0); /* release the saved handle *./ /* write whatever we want to pipe */ Fwrite(pfd[1], (long)strlen(data), data); /* close write side */ Fclose(pfd[1]); You could also use multiple pipes to run several programs in a chain. You can also use Fdup / Fforce once on two different programs and Pexec one to write to the pipe and the other to read. For example, the equivalent (in simple terms) of the shell command "prog1 | prog2" can be done with: int sav0, sav1; int pfd[2]; Popen(pfd); sav1 = Fdup(1); Fforce(1, pfd[1]); Pexex(100, "prog1.prg", tail, env); Fforce(1, sav1); sav0 = Fdup(0); Fforce(0, pfd[0]); Pexec(0, "prog2.prg", tail, env); Fforce(0, sav0); Fclose(pfd[0]); Fclose(pfd[1]); Fclose(sav0); Fclose(sav1); > >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." P.O. Box 21575, Oakland, CA 94620 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |
piet@cs.ruu.nl (Piet van Oostrum) (02/03/90)
Would somebody care to describe exactly under what circumstances you run into the TOS redirection bug? -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')
ONM07@DMSWWU1A.BITNET (Julian Reschke) (02/06/90)
In article <1990Jan22.173721.12285@stag.UUCP> Dale Schumacher writes: > On a related point, there has been some movement to correct a long-standing > inconvenience in TOS regarding stderr. Handle 2 is connected to the AUX > port by default, but I support it's use as a redirectable stderr. To > force this to work properly, C start-up code should check to see if handle > 2 is a tty. If is IS, then Fforce() it to -1 to attach it to the console. > This is harmless if it already IS attached to the console, and makes sure > you don't confuse your serial i/o device if it's still attached to AUX. > If handle 2 IS NOT a tty, leave it alone, since that should indicated that > someone has redirected it. But this will fail if you try to redirect handle 2 to PRN:! Correct me if I'm wrong... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Tel.: 0251/861241 eMail: ONM07@DMSWWU1A.BITNET
bammi@curie.ces.CWRU.Edu (Jwahar R. Bammi) (02/07/90)
In article <9001301152.AA03348@freya.dmswwu-ether> ONM07@DMSWWU1A.BITNET (Julian Reschke) writes: dale: > inconvenience in TOS regarding stderr. Handle 2 is connected to the AUX > port by default, but I support it's use as a redirectable stderr. To > force this to work properly, C start-up code should check to see if handle > 2 is a tty. If is IS, then Fforce() it to -1 to attach it to the console. Julian: But this will fail if you try to redirect handle 2 to PRN:! Correct me if I'm wrong... thats correct, but dales suggestion is still fine. its isatty() that needs to be fixed up, so that it does'nt think that PRN: isatty(). (just out of curiosity, why would someone send stderr to PRN:? why not to a file, and then if its really needed, print the file (saves a few trees in the process)). -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
ONM07@DMSWWU1A.BITNET (Julian Reschke) (02/09/90)
In article <BAMMI.90Feb6182843@curie.ces.CWRU.Edu> Jwahar R. Bammi writes: > thats correct, but dales suggestion is still fine. its isatty() that > needs to be fixed up, so that it does'nt think that PRN: isatty(). > (just out of curiosity, why would someone send stderr to PRN:? why not > to a file, and then if its really needed, print the file (saves a few > trees in the process)). I think that this is a very natural thing to do with stderr. IF we try to suggest a good method, it should be possible to do all things that you do with sterr on other OS's. If Atari makes a workings suggestion, it will be surely incorporated in Gemini 1.2. ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 eMail: ONM07@DMSWWU1A.BITNET, "Julian Reschke" @ MAUS MS (++49 251 80386) ____________________ correct me if I'm wrong _____________________________
roeder@sbsvax.cs.uni-sb.de (Edgar Roeder) (02/10/90)
In article <BAMMI.90Feb6182843@curie.ces.CWRU.Edu>, bammi@curie.ces.CWRU.Edu (Jwahar R. Bammi) writes: > In article <9001301152.AA03348@freya.dmswwu-ether> ONM07@DMSWWU1A.BITNET (Julian Reschke) writes: > dale: > > 2 is a tty. If is IS, then Fforce() it to -1 to attach it to the console. > Julian: > But this will fail if you try to redirect handle 2 to PRN:! Correct me if > I'm wrong... > > thats correct, but dales suggestion is still fine. its isatty() that > needs to be fixed up, so that it does'nt think that PRN: isatty(). Here are my two cents: What if the user wants to redirect handle 2 stderr to the serial port (AUX:)? Since this is the default assignment for this handle it will be difficult to manage this case too. I had two applications for this. Some time ago i wanted to debug a full screen editor (not emacs :- ) and have sent the debug output to a PC clone. I needed this output while i was testing the program, not later. Therefore i could not use a file. The second application needs to redirect all standard handles (stdin, stdout, stderr). It's a program to run eg. games in a mailbox (for example nethack). Then stderr IS a terminal, but not the console. And the mailbox user will not like to play on the console screen (unless he/she is clear-sighted :-) or sitting before the console). > -- > bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi > domain: bammi@dsrgsun.ces.CWRU.edu > GEnie: J.Bammi - Edgar -- Mail: Edgar R\"oder E-Mail: roeder@cs.uni-sb.de Liesbet-Dill-Stra\ss e 3 D-6602 Dudweiler -o- -o- W-Germany ^ Phone: 06897/74643 '---'
7103_2622@uwovax.uwo.ca (Eric Smith) (02/10/90)
In article <9002081436.AA09758@freya.dmswwu-ether>, ONM07@DMSWWU1A.BITNET (Julian Reschke) writes: > In article <BAMMI.90Feb6182843@curie.ces.CWRU.Edu> Jwahar R. Bammi > writes: >> thats correct, but dales suggestion is still fine. its isatty() that >> needs to be fixed up, so that it does'nt think that PRN: isatty(). >> (just out of curiosity, why would someone send stderr to PRN:? why not >> to a file, and then if its really needed, print the file (saves a few >> trees in the process)). > I think that this is a very natural thing to do with stderr. IF we try > to suggest a good method, it should be possible to do all things that > you do with sterr on other OS's. If Atari makes a workings suggestion, > it will be surely incorporated in Gemini 1.2. [Dale's suggestion was for startup code to do something like if (isatty(2)) Fforce(2, -1).] How about this suggestion: if all programmers who use the Atari extended argument passing scheme (ARGV=, etc.) also agree that handle 2 should be stderr, then startup code could do: if (*argv[0] == 0 && isatty(2)) Fforce(2, -1). (This assumes that argv[0] is an empty string if it isn't available, as specified by the ANSI standard). This way, ARGV compatible shells can redirect stderr to anything at all; non-ARGV compatible shells can redirect stderr to a file; and programs still correctly re-direct handle 2 when run from the desktop. -- Eric R. Smith email: Dept. of Mathematics ERSMITH@uwovax.uwo.ca University of Western Ontario ERSMITH@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638