From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108260358.AA18597@clio.rice.edu>
Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K)
To: acottrel AT ihug DOT com DOT au (Andrew Cottrell)
Date: Sat, 25 Aug 2001 22:58:38 -0500 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-Reply-To: <00bc01c12ddd$cd6c8c70$0a02a8c0@acceleron> from "Andrew Cottrell" at Aug 26, 2001 01:18:38 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Could someone please correct me on redirection and pipes as my understandign
> is a little lacking in that I do not see how we change the way they are used
> from an application of my understanding of these is correct. The following
> is my understanding and it appears to be eiher wrong or missing something:
>     a) redirection uses "<" and ">"
>     b) redirection can be either input or output
>     c) Pipes uses "|"
>     d) Pipes are only output from prog1 to prog2, eg prog1 | prog2
>     e) Redirection and pipes are a function of the shell used

These are all correct (you can also redirect stderr).

Primative DOS systems (DOS, Win9x) emulate pipes by running prog1, 
redirecting output to a file, completing.  Starting prog2 with file
as input.  Real operating systems (NT, Unix) start both applications
at once and just move the bytes in memory, making prog1 wait until
prog2 reads the data stream (subject to buffering data in the pipe).

The problem we have with NT is _get_dev_info() on pipes does not show
them to be any different than a file.  My testing indicates that 
NT is actually making a redirected file behave much like a pipe on
the handle (why there are seek problems and the seeks and reads must
be sync'ed).

> > What about having _get_dev_info be smart about these?
> If this works then it would eleviate the other patches and not slow down any
> library calls, except the _get_dev_info call.. What about the case where
> _get_dev_info is not called before a call to 3F00 was done on STDIN? In this
> case would it be better to think about having the change (if it can be done)
> in crt1.c so it gets done before the application starts?

If someone is blindly performing read() calls mixed with seeks on STDIN
assuming it's a file without checking, it's nonportable and a bug.