Date:	Tue, 8 Jul 1997 13:27:35 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Esa DOT Peuha AT Helsinki DOT FI
cc:	djgpp AT delorie DOT com
Subject:	Re: interesting redir behavior
In-Reply-To:	<Pine.SOL.3.96.970708113008.13215A-100000@kruuna.Helsinki.FI>
Message-ID:	<Pine.SUN.3.91.970708131641.13521B-100000@is>
MIME-Version:	1.0

On Tue, 8 Jul 1997, Esa A E Peuha wrote:

> On Tue, 8 Jul 1997, Eli Zaretskii wrote:
> 
> > IMHO, this should be reported to Caldera.  It seems that it doesn't 
> > behave like DOS when allocating file handles.  `redir' relies on the 
> > fact that when you close handle x, the next open reuses that handle.
> > If this is false in OpenDOS, the redirected file will remain empty.
> 
> Shouldn't redir use DOS function 0x46 (Force duplicate file handle) and
> not rely on undocumented behavior.

`redir' does use `dup' and `dup2', but it is not enough.  If `open' after 
"close(1)" doesn't return 1, then the redirected file is not open on 
stdout (which is always handle 1).  Since the program invoked by `redir' 
will use handle 1 as stdout, you need to make sure redirected file is 
assigned handle 1 and nothing else.

The `dup' calls force the new handle to refer to the same file/device as 
the other handle, but they create a new handle, they cannot be used to 
force the new handle be 1 (or any other specific number).  The numbering 
of handles is done by the OS.

I'm not sure that the behavior assumed by `redir' is undocumented, but 
even if it is, it is a long-time de-facto standard (in Unix also), 
because redirection, including the "foo > bar" thing supported by 
COMMAND.COM would never work without that (and don't ask me how does it 
work in OpenDOS's COMMAND.COM).

- Raw text -