Mail Archives: djgpp-workers/2001/08/26/00:54:41
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
----- Original Message -----
From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
To: <eliz AT is DOT elta DOT co DOT il>
Cc: <acottrel AT ihug DOT com DOT au>; <djgpp-workers AT delorie DOT com>
Sent: Sunday, August 26, 2001 2:52 AM
Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN
problem on Win 2K)
> > > 3) This problem is masked on 2.03 due to call sequences which are
different
> > > (when using fstat, no one calls the get magic manually).
> >
> > ??? What do you mean by that? fstat _always_ tries to get the magic
> > number if the handle refers to a file (not a character device).
>
> If you call get_magic under 2.03 you can see the problem, but if you
> call fstat() - which calls get_magic, you don't. So some sequence of
> additional calls on the handle under 2.03 makes the problem go away.
> More testing to find out why. What if we find some other interrupt
> called before _get_magic on the same handle prevents the problem? That
> would be a much better fix than slowing down each an every _read.
See my other email about a refined example.
> > > 4) This problem is masked on 2.04 if lfn=n due to call sequence
differences
> > > (when using fstat).
> >
> > And just to be sure we are talking about the same issue: by ``this
> > problem'' do you mean the weird behvaior of read and lseek wrt file
> > position? Or is there anything else?
>
> The problem specifically is Andrew's original test problem using fstat()
> on stdin and that causing subsequent calls to read to have missed the
> first 2 characters in the file.
This is why it has taken me so long to figure out that the 3F00 call is the
root problem.
> > > What I think, but must be confirmed:
> > > 1) This problem is only seen on handle 0 when opened by NT, not Bash
> >
> > I think you saw similar problems on handle 1. The current hypothesis
> > is that any handle opened by the NT shell will behave like that, which
> > means handles 0-4 could potentially be affected.
>
> I saw other problems on handle 1 - since reads failed completely on handle
> 1 there were not any missing data or offset problems. But getting the
> current position did return bogus values on appended files. This could
> eventually cause us to destroy all data in an appended handle by writing
> to the start instead of appending.
>
> > Sounds like a good plan to me. But if an extra seek solves the
> > problem, why not try use it? We could make it part of this testing as
> > well, to see whether it indeed solves the problems.
>
> _read() is one of the most heavily used calls in the library. For all
> DOS 5 systems we will be adding an extra interrupt to get true dos
> version. For all NT systems we will be adding two new interrupts for
> every read, the get dos version and a seek. And this may be for
> a very specific problem that we don't even fix completely!
I have patched the LIBC I am using so that I can get patch working on Win2K.
I updated the pat253b.zip file on the unofficial DJGPP Win 2K web site so
people can download a functioning patch for Win 2K. I have not updated LIBC
as the exact change is still not decided and will change.
>
> if we patch _read(), I would want a static variable for true_dos_version
> set up, and to only do this for handle 0. If we are doing this, let's
> also have get magic call _read instead so we don't have the patch multiple
> places.
I think that we do need to introduce a varable or a set of variables that
holds the true OS info at some stage. The real issue here is do we do it now
or later? When it is done then someone needs to go through the code and
cleaup all of the exisitng tests to use the new variable(s). I would rather
get the exisitng code working and then we can let more people test it while
it is being cleaned up and optimized, this does not mean that we cannot add
the variables now and start using them. I have done similar cleanup work
previously and it is time consuming and as such would be best left until we
get into the testing phase.
My vote is that we add a variable or set of variables now and start using
them on any mods from now on and then go back later and perfrom a cleanup.
> > > A similar problem is seen when redirecting from NUL for example - this
is
> > > shown as a regular file. We shouldn't be seeking on NUL, or reading
> > > magic numbers, but we do today.
> >
> > We seek on NUL because we don't know it's a character device.
>
> Exactly. I think we should fix the root problem of the strange redirected
> handles instead of adding new interrupt calls to routines which will
> slow everything down.
>
> 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?
- Raw text -