Date:	Sun, 16 Nov 1997 13:34:11 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Michael Mauch <michael DOT mauch AT gmx DOT de>
cc:	djgpp AT delorie DOT com
Subject:	Re: RHIDE -- author(s) please read this
In-Reply-To:	<346e3480.11667399@unidui.uni-duisburg.de>
Message-ID:	<Pine.SUN.3.91.971116133343.358A-100000@is>
MIME-Version:	1.0

On Thu, 13 Nov 1997, Michael Mauch wrote:

> Hmm, I checked that and it only kind of works (at least here, on Win95):
> if stdin is not redirected, it waits until you press key and then
> prints

It waits for a key or for a time-out (at 15 seconds).  That's how the
test program calls `select' in this case (see the source).  The key
part is because when stdin is not redirected, it is NOT ready for
input unless you provide some input by pressing a key.  Testing for
that is exactly what `select' is about.

> But if stdin is redirected, it immediately prints:
> 
> 0:  ready for input
> 0:  ready for output

Disk file is *always* ready for output in DOS, and is ready for input
as well unless it's empty.  `select' just reports to you what DOS
says.  I don't see anything wrong with that.

> in that case, stdout never becomes ready for input and select() waits
> for 15 seconds before printing
> 
> 1: NOT ready for input
> 1:  ready for output

Don't see anything wrong here either.  The wait is because of the
`input' part (it's OK to have stdout not ready for input).

Btw, the results depend to where did you redirect stdout.  Try
redirecting stdout to NUL and see an immediate report.  That's because
the NUL device is ready to do anything.

Also, try redirecting stdin to an empty vs non-empty file, and observe
the difference.  

All of the above is both what DOS does and IMHO intuitively
understandable.

- Raw text -