Date: Tue, 8 Jul 1997 13:27:35 +0300 (IDT) From: Eli Zaretskii To: Esa DOT Peuha AT Helsinki DOT FI cc: djgpp AT delorie DOT com Subject: Re: interesting redir behavior In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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).