Sender:	edevaldo AT pobox2 DOT mot DOT com
Message-ID:	<37B4186B.9344D7CC@motorola.com>
Date:	Fri, 13 Aug 1999 10:06:51 -0300
From:	Edevaldo Pereira da Silva Junior <Edevaldo DOT Pereira AT motorola DOT com>
Organization:	Motorola - Semiconductor Products Sector
X-Mailer:	Mozilla 4.07 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Subject:	Re: TCL Port to DJGPP - Bug + Advices.
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990805100812 DOT 14908F-100000 AT is>
X-Motorola-Sent-Wireless:	1
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Wed, 4 Aug 1999, Edevaldo Pereira da Silva Junior wrote:
> 
> >       One more question. Is there a way, in DJGPP, to write to the standard
> > input of a program, run it and the read it's standard output?
> >       I'm asking that because reading popen and pclose documentation I got
> > the impression that I can only write to the standard input or read the
> > standard output. Not both. Am I right?
> 
> Yes, you are right.  If you need two-way communications to the
> subprogram, you will have to add some code.  For example (UNTESTED):
> 
>         FILE *fptem, *fpipe;
>         char tem_name[L_tmpnam], cmd_line[L_tmpnam + FILENAME_MAX + 4];
> 
>         fptem = fopen (tmpnam (tem_name), "w");
>         fprintf (fptem, ....); /* write program's input to temp file */
>         fclose (fptem);
>         sprintf (cmd_line, "prog.exe < %s", tem_name)
>         fpipe = popen (cmd_line, "r");  /* run the program */
>         remove (tem_name);              /* delete temporary file */
>         fread (fpipe, ... );            /* read program's output */
>         pclose (fpipe);                 /* close the pipe */
> 
> Note that I left out a lot of error-checking.  In particular, popen
> and pclose can return error indications that you shouldn't ignore.
> 
> Btw, I suggest to use "prog.exe" in the command line and not just
> "prog" because that makes the error checking smarter: in the former
> case you will get NULL from popen and errno will be set to ENOENT if
> the program isn't found, while in the latter case you will only see
> "Bad command or file name", since popen will eventually call
> COMMAND.COM.

	This helped a lot Eli thanks! Now, most of the pipe emulation inside
TCL is working, but there still some corners to be adjusted.
	Redirection of the stderr is one of then. I looked inside redir to
figure out how this is done. It is implemented using dup & dup2
functions.
	I was thinking about using dup & dup2 to make the stderr point to a
tempfile then call "prog.exe" with system or popen. What I do not know
is how to make the stderr point to the right place again once the
prog.exe has finished. Any suggestions?

	Another question: Regarding file descriptors, is it usual that the
descriptors 0,1 & 2 will always point to stdin,stdout & stderr
respectively? Is it standard across platforms?

	Thanks again.
	Regards,

				Edevaldo

- Raw text -