🚀 go-pugleaf

In article <DI3BnA.JF5@news.zippo.com>,  from Wed, 15 Nov 1995 15:16:38 GMT 
Fred Frot at Fred.Dullemond@Austria.ATTGIS.COM says...
>
>
>Hello,
>
>At the moment I am developing some kind of tool to call (spawn/exec)
>other commands (using swap of memory) in MS-DOS.
>
>In order not to disturb the screen by messages from the called program
>I use redirection of stdout.
>
>        e.g. 'dir > \it.txt'
>
>I encountered a problem when this called program writes something to
>stderr. These messages are not redirected to the file, but corrupt the
>screen display and confuse the ignorant user.
>
>So I want to do something like under UNIX command-line :
>
>        ls > /dev/null    2>&1
>
>or redirecting the stderr in the calling program to stdout (which I
>think would be the best), but I don't know how to do this.
>

	Seems you want to redirect *all* output from the called command ?

	Instead of calling the command directly, enclose the command
	in a batch file:

		@echo off
		ctty nul
		command-to-call
		ctty con

	and then call COMMAND.COM /C d:\path\that_batch.bat



-- 
    Ed Schwartz
+------- e-mail --------------+--- s-mail ----+---- Phone/Fax ---------+
| schwartz@sunco.co.kp.dlr.de | DLR/RM-CTC    | Tel.: (0)2203-601 2648 |
| Edwin.Schwartz@dlr.de       | Linder Hoehe  | Fax : (0)2203-601 2701 |
|                             | D-51147 Koeln |                        |
| http://www.dlr.de           | Germany       |                        |
+-----------------------------+---------------+------------------------+

Fred.Dullemond@Austria.ATTGIS.COM (Fred (Frot)) wrote:


>Hello,

>At the moment I am developing some kind of tool to call (spawn/exec)
>other commands (using swap of memory) in MS-DOS.

>In order not to disturb the screen by messages from the called program
>I use redirection of stdout.

>	e.g. 'dir > \it.txt'

>I encountered a problem when this called program writes something to
>stderr. These messages are not redirected to the file, but corrupt the
>screen display and confuse the ignorant user.

>So I want to do something like under UNIX command-line :

>	ls > /dev/null    2>&1

>or redirecting the stderr in the calling program to stdout (which I
>think would be the best), but I don't know how to do this.

>	void main() 
>	{
>		......... 			// Some code
>		
>		fclose(stderr); 		// I know this does not work,
>					// but the intention is closing the stderr for the next prog.
>		spawnv(P_WAIT, .........) ; 	// Call the programm

>		freopen(stderr), 		// Does not work either, but reopen the stderr
>is
>					// needed for its own messages.
>		........... 			// Some error detection from spawn
>	}

>If someone could shine some light on this, I would be very gratefull !

>Fred

>Fred.Dullemond@Austria.attgis.com

Thanks to all of you who reacted to my post.

I think the original post was a little bit unclear, since most of the
answers were concerning redirecting stderr WITHIN MSDOS, like

                ctty nul
                command-to-call
                ctty con

But this is NOT what I want. 

I am writing a C program that has a shell-function. I present the user
a menu with commands to select and within the C programm I call a
SPAWN/EXEC.. c-function which handles the called programm.

Once this called programm has finished, my programm goes on.

Since I want MY program (shell) to handle all the screen output, the
called programs output must be captured somehow. 

So I need some C-CODE which allows me to redirect the stderr &| stdout
to something else.

Fred

Fred.Dullemond@Austria.ATTGIS.COM (Fred (Frot)) wrote:

>Fred.Dullemond@Austria.ATTGIS.COM (Fred (Frot)) wrote:

[snip]
>So I need some C-CODE which allows me to redirect the stderr &| stdout
>to something else.

>Fred

To do this you will need to use file handle functions instead of the
standard C functions.  On the compiliers I'm used to the functions
needed are called open() and close() and are declared in dos.h
(consult your compilier manual for details).

To redirect stdin, stdout, or stderr to a file called myfile do
something like this:
--- start psuedocode
  int handle, handle2, handle 3;

  /* redirect standard file handle */  
  handle2 = open("myfile", /*permission flags etc */ );
  
   dup2(handle2, handle);   
  /* handle should be
      0 for stdin,
      1 for stdout,
      2 for stderr,
      3 for stdaux
      and 4 for stdprn  
      The old  file referenced by handle is closed if neccessary
       I don't know if dup2 is supported by M$ compiliers*/

     /* exec program */

     /* restore standard file handle */

      handle3 = open(newfile, /*permission flags */);  
      /* new file should be "CON" for the screen, "AUX"  for

         auxilliary, PRN for printer */

       dup2(handle3, handle);
---end psuedocode

    I just wrote this on the fly, so there could be some problems with
it,  but I'm pretty sure this is the way to redirect  stdin, stdout,
etc.  

    Good Luck!

Dusty Reichwein
reichwej@ucs.orst.edu

voyageur@solar.sky.net () recently put forth:


>| The only way I know of redirecting STDERR is to write an INT 21h 
>| handler.  STDERR is File Handle 0002, and STDOUT is 0001.  You would need 
>| to intercept AH=40h writes to Handle 0002, change BX=0001, call the 
>| previous INT 21h handler, and switch BX back to 0002.

	There are specific INT 21H functions to do this, namely, funct 45h &
46h.




--
Mark R.
===========================
mrestifo@wizvax.net
102444,3171@compuserve.com
===========================

Raymond Moon (raymoon@moonware.dgsys.com) wrote:
: Fred (Frot) wrote:

: > At the moment I am developing some kind of tool to call (spawn/exec)
: > other commands (using swap of memory) in MS-DOS.
: > 
: > In order not to disturb the screen by messages from the called program
: > I use redirection of stdout.
: > 
: >         e.g. 'dir > \it.txt'
: > 
: > I encountered a problem when this called program writes something to
: > stderr. These messages are not redirected to the file, but corrupt the
: > screen display and confuse the ignorant user.
: > 

'>' redirects stdout but it doesn't redirect stderr try '>&' (it's been a
long time so i'm not sure if this works)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              dcarapic@fly.cc.fer.hr - dalibor.carapic@fer.hr
            Dalibor Carapic - Fakultet Elektronike i Racunarstva		

Our Program, who art in memory. Hello be thy name. Thy operating system come,
 thy command be done, at the printer as they are on the screen. Give us 
  this day our daily data, and forgive us our errors as we forgive those  
   whose logic circuits are faulty. Lead us not into frustration, and 
    deliver us from power surges. For thine is the algorithm, 
     the application, and the solution, looping forever and ever. 
                      Return.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <49bt2q$sl3@bagan.srce.hr>, dcarapic@fly.cc.fer.hr says...
>
>Raymond Moon (raymoon@moonware.dgsys.com) wrote:
>: Fred (Frot) wrote:
>
>: > At the moment I am developing some kind of tool to call (spawn/exec)
>: > other commands (using swap of memory) in MS-DOS.
>: > 
>: > In order not to disturb the screen by messages from the called 
program
>: > I use redirection of stdout.
>: > 
>: >         e.g. 'dir > \it.txt'
>: > 
>: > I encountered a problem when this called program writes something to
>: > stderr. These messages are not redirected to the file, but corrupt 
the
>: > screen display and confuse the ignorant user.
>: > 
>
>'>' redirects stdout but it doesn't redirect stderr try '>&' (it's been a
>long time so i'm not sure if this works)


Inside your code, before you execute your spawn or exec, try the 
following:

                 close(2);

or
 
                 fclose(stderr); /* Assuming <stdio.h> */


I tested this with MSVC++ 1.5 (though I used the "system" function)
and it seemed to work okay. If you actually want to keep stderr available
for your use, you can dup or dup2 it, then close it, and re-dup or dup2
it.

                              Fred