From: heard@public.BTR.COM (Charles M. Heard  heard@btr.com)
Newsgroups: comp.sys.ibm.pc.programmer,comp.os.msdos.programmer
Subject: Re: Redirecting STDERR
Summary: patch to command.com allows subsequent redirection
Date: 11 Nov 92 03:00:49 GMT
Article-I.D.: public.8293
Followup-To: comp.sys.ibm.pc.programmer
Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM

In article <1992Nov9.151005.8011@informatik.uni-wuerzburg.de> schoof@dec5.informatik.uni-wuerzburg.dbp.de (Jochen "Joscho" Schoof) writes:
>From article <1992Nov05.042258.126673@zeus.calpoly.edu>, by mwormley@zeus.calpoly.edu (Matt Wormley):
>[some lines deleted]
>> 
>>    Doesn't >& work for redirecting both stdout and stderr?  I think that's
>> it. 
>> 
>>     worm
>
>Sure it does, but only if you use a proper shell like 4DOS! 
>- Jochen

Right.  In fact, command.com interprets the ampersand as the first character
of the target file to which stdout is being redirected.  The following is what
happens under DOS 3.3;  the same effect (with small variations in the
dialogue) occurs in DOS 5.0.

B:\>if exist &nul del &nul

B:\>c:\dos\comp *.@@@ *.@@@ >&nul

Compare more files (Y/N)?
B:\>dir

 Volume in drive B has no label
 Directory of  B:\

BACKUPID @@@      128  11-07-92   9:43a
ARTFORM  ZOO   356859  11-07-92   2:20a
&NUL               85  11-08-92   3:04p
        3 File(s)      3072 bytes free

B:\>type &nul

B:BACKUPID.@@@ and B:BACKUPID.@@@ 

Eof mark not found

Files compare ok
n

One work-around for this particular piece of DOS brain-damage
was presented in <klosp.25.720972094@rimail.interlan.com> by
klosp@rimail.interlan.com (Patrick Klos), who writes:

>[some lines deleted]
>
>Here's a dirty little program that easily forces anything from STDERR to 
>STDOUT.  Maybe this will do the trick for you!
>
>[followed by source code for a TSR which redirects all I/O from handle 2
>(stderr) to handle 1 (stdout), also deleted]

Another way is to install a patch having the same effect in command.com.
The following dialog does this to the DOS 5.0 command.com and saves the
patched version to errout.com.  The same technique works for DOS 3.3
provided that you make the necessary adjustments to the addresses.

C:\>debug command.com <errout.rsp
-r
AX=0000  BX=0000  CX=BAE5  DX=0000  SP=FFFE  BP=0000  SI=0000  DI=0000  
DS=229A  ES=229A  SS=229A  CS=229A  IP=0100   NV UP EI PL NZ NA PO NC 
229A:0100 E95D14        JMP	1560                               
-a bbe5
229A:BBE5 mov ax,4600       <---- function 46h = force duplicate handle
229A:BBE8 mov bx,0001       <---- open handle to be duplicated (stdout)
229A:BBEB mov cx,0002       <---- open handle to be redirected (stderr)
229A:BBEE int 21
229A:BBF0 jmp 1560
229A:BBF3 
-a 0100
229A:0100 jmp bbe5
229A:0103 
-rcx
CX BAE5
:bbf3
-
-n errout.com
-w
Writing 0BBF3 bytes
-q


One may now redirect stderr  and stdout from whatever program, batch file, or
DOS internal command one wishes as follows:

C:\>errout /c -DOS-COMMAND-LINE- >OUTFILE

(other redirections i.e. >> and | also work).  Compared to Patrick Klos's
TSR this generally uses more memory since it loads a secondary command 
processor (although you have to do this anyway to redirect the output from
a batch file), but it has the advantage of allowing the program or batch file
which is invoked to redirect stdout to a file different from OUTFILE if it
needs to.  I have used this technique under both DOS 3.3 and DOS 5.0 to
redirect error messages from software library build scripts in which
revision history information normally produced on stdout is redirected to
a temporary file for subsequent processing.

C. M. Heard
heard@btr.com
Newsgroups: comp.sys.ibm.pc.programmer,comp.sys.ibm.pc.hardware,comp.lang.pascal,alt.hacker,alt.binaries.sound.misc