From: Christopher Croughton <crough45 AT amc DOT de>
Message-Id: <97Jul8.164038gmt+0100.16641@internet01.amc.de>
Subject: Re: interesting redir behavior
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Tue, 8 Jul 1997 15:44:50 +0100
Cc: crough45 AT amc DOT de, djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.970708165630.13991G-100000@is> from "Eli Zaretskii" at Jul 8, 97 03:03:04 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:

> DJ should answer that.  But AFAIK, the way `redir' works is quite common 
> practice; I've seen many programs doing that, and OpenDOS will break all 
> of them.  For example, Less is one of them.

Hmm.  I've always viewed that as potentially dangerous behaviour, because
I've don't remember any O/S specification which guarantees that an open
always gets the lowest available file descriptor.  Relying on undocumented
behaviour can work most of the time, but when it fails (as has happened a
lot with versins of MSDOS, for instance) it can cause problems.  (Much the
same has happened to me by relying on the unbuffered nature of stdout,
for example, and then not seeing lines without newline.)

> If memory serves, all of these use `dup2' and/or `freopen'.

For good reason - it's perfectly valid for a program to close stdin
before calling system etc., which will get the wrong things reassigned
if they just go for the O/S's returned FD.  If the program (like REDIR)
knows it isn't doing that then it can make some more assumptions, as
long as the O/S cooperates...

Chris C