X-Authentication-Warning: smtp3.ihug.com.au: Host p15-max10.syd.ihug.com.au [203.173.155.15] claimed to be acceleron
Message-ID: <006f01c12baa$75006780$0a02a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc: <sandmann AT clio DOT rice DOT edu>, <djgpp-workers AT delorie DOT com>
References: <10108200508 DOT AA15103 AT clio DOT rice DOT edu> <2950-Mon20Aug2001093159+0300-eliz AT is DOT elta DOT co DOT il> <002501c12980$4c67fa80$0a02a8c0 AT acceleron> <2110-Mon20Aug2001172450+0300-eliz AT is DOT elta DOT co DOT il> <001101c12a42$7776d850$0a02a8c0 AT acceleron> <8011-Tue21Aug2001200758+0300-eliz AT is DOT elta DOT co DOT il> <00ae01c12b02$75f9d200$0a02a8c0 AT acceleron> <200108221430 DOT KAA02730 AT delorie DOT com>
Subject: Re: Fseek on STDIN problem on Win 2K
Date: Thu, 23 Aug 2001 18:06:03 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Reply-To: djgpp-workers AT delorie DOT com

> > seek.c 172 4200, flags = 0x02 pos = 0x0000:0000   Char at offset [0] =
(3)
> > seek.c 172 4200, flags = 0x02 pos = 0x0000:0000   Char at offset [0] =
(4)
>
> It looks like 4200 reports that it did move the file pointer, but the
> subsequent 3F00 still continues from the position before the lseek.
>
> > After I wrote the sentence above I thought that the possibel solution is
to
> > add a seek to position 1 after the 3700 call and then to seek to zero. I
> > just tested this an it works. To include the change I found works change
the
> > AC_PATCH_TEST_1  define to 1, to go back to the old code change the
define
> > to 0.
> >
> > There are other changs in the code that I am working on, for example
move
> > the processing of the retval to just after the 3700 call so that the
> > additional code will not overwrite the buffer.
> >
> > What do you think about this sort of solution for is_executable()?
>
> Right now, I'm more worried by lseek not working than by
> _is_executable.  I think we need first to find a good general-purpose
> solution for lseek, so that we could be sure the file pointer moves to
> the right place.  If that doesn't fix _is_executable, we can find some
> local trick later.
>
> > Thanks for this as it explains how come I could not see this anywhere as
it
> > is up to the shell used. I wonder if bash or 4DOS shell has work?  I
will
> > also try this if I have time tomorrow night.
>
> Thanks, trying this with different shells might indeed shed some light
> on this problem.
4DOS - also fails.
Bash 2.05 beta - Works, same as Charles found.

I have read all of the email going arround and I would like to find out what
I can do to help out with this issue as some of the info in the emails went
over my head.