Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!ruuinf!piet
From: piet@cs.ruu.nl (Piet van Oostrum)
Newsgroups: comp.sys.atari.st
Subject: I/O Redirection
Message-ID: <1793@ruuinf.cs.ruu.nl>
Date: 13 Nov 89 14:24:42 GMT
Sender: news@ruuinf.cs.ruu.nl
Reply-To: piet@cs.ruu.nl (Piet van Oostrum)
Organization: Dept of Computer Science, University of Utrecht, Holland
Lines: 64

It seems that I am having some problems with I/O redirection. What I do to
exec a child with e.g. the stdout to some file:

	temp1 = Fdup(1);			/* save old stdout */
	temp2 = open ("filename", O_WRONLY); 	/* Fopen or Fcreate */
	if (temp2 < -3) {printf ("error");}
	Fforce (1, temp2);			/* set new stdout */
	Fclose (temp2);				/* no use for temp2 anymore */
	Pexec (......);				/* start child */
	Fforce (1, temp1);			/* reset stdout */
	Fclose (temp1);				/* no use for temp1 anymore */

Could it be that the close statements are giving problems?? It is not
completely clear to me what is going wrong, but I have had strange
malfunctions after execing a child like this. It could be that it has to do
with using GULAM as a shell. I remember a question from Jahwar Bammi about
this subject earlier this year, where a redirection gave also similar
problems. I copy it to the end of this posting.

 Could someone from Atari speak about the above code. Is this the correct
way to do things?

From bammi's posting:

i had tried to include a redirection for stderr to console, so that
gcc applications would not need a wrapper shell to run in by doing
a 
	Fforce(2,(short)Fdup(1))
in crt0.s. This works fine, until you try to redirect stdout from
a shell (like gulam)
	a.out > foo
what happens is that stdout and stderr end up in foo (another exotic TOS
bug -- is this fixed in tos 1.4??)
Now if you try to run this program a second time:
	- i get error code -61
	- eric smith reported that some files got trashed
so depending on your setup, i suspect one of the two will happen.
Please apply the patch enclosed below that backs out these changes, and
recompile and install crt0.o in $GNULIB. Hopefully we will come up
with a better scheme for stderr soon:
--
*** crt0.s~	Fri Mar 10 16:00:34 1989
--- crt0.s	Fri Mar 10 16:01:00 1989
***************
*** 146,162 ****
  |	movw	d3, sp@-		| push argc
  	movel	d3,sp@-			| .. jrd
  
- 	movw	#1, sp@-		| set up stderr  ++jrb
- 	movw	#0x45,sp@-		| Fforce(2,(int)Fdup(1))
- 	trap	#1
- 	movw	d0,sp@-
- 	movw	#2,sp@-
- 	movw	#0x46,sp@-		| Fforce
- 	trap	#1
- 	lea	sp@(10),sp		| adjust stack
- 
- 	subl	a6, a6			| clear link reg - why I don't know
- 
-- 
Piet* van Oostrum, Dept of Computer Science, University of Utrecht
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')