From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10108231331.AA18728@clio.rice.edu>
Subject:	Re: Fseek on STDIN problem on Win 2K
To:	eliz AT is DOT elta DOT co DOT il
Date:	Thu, 23 Aug 2001 08:31:13 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<2110-Thu23Aug2001091047+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 23, 2001 09:10:48 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> > does the 2.03 library not call the is_executable?
> 
> Yes, it does.

My brain hurts.  Why oh why does it work with 2.03?

> > fstat() doesn't cause this problem in 2.03 which might explain why
> > it's more rare).
> 
> So perhaps we should find out which change since v2.03 triggers this.

Yes.

> > I tried test >> testout
> > I tried test >> nul
> > 
> > fstat() is OK with handle 1, in both cases thinks it's a file, lseek
> > says it's at the beginning (0) wrong for file append.
> 
> Does lseek say it's at the beginning for a non-empty file
> testout as well?  If so, this doesn't happen on Windows 98.

Yes, it says at beginning for non-empty file.  Even for 2.03 .

> The time for NUL should be the current time, but that code only works
> if fstat detects that it's a device, which I presume isn't happening
> on NT?

NUL is not seen as a device on redirection under NT 4.0 but as a file.

> > In both cases _read fails on the handle.
> 
> Fails how?  Do you mean to say that NT disallows reads on stdout?  It
> does work on Windows 98: I redirected stdout into a raw COFF file, and
> fstat readily reported it's an executable.

I didn't print the errno, but yes _read fails on stdout with NT 4.0 when
redirected to file

> > Proposal:  fstat() (or dev info?) does the following:
> >   if dev_info == 0 and NT and handlenumb <5 dev_info = 0x8000
> 
> How is this better than leave the current problems with fstat intact?
> (Admittedly, I don't remember anymore why this was a grave problem ;-)

If it's a device, we don't call magic number, and no applications try
to seek on it (so it fixes Andrew's problem).

Since it's a device, we discourage reading from an outgoing pipe.

I think it's a defensive measure.

> Also, I think Bash uses handle 5 quite a lot in configure scripts, and
> the programs it invokes inherit the redirection.  (Mark, am I right?)
> Does redirection from Bash have this problem?  (I think you said no,
> but I'm not sure.)

I was thinking for handles 0,1,2 especially.  3&4 unknown.  Don't want to
touch 5  or above.

- Raw text -