Mail Archives: djgpp-workers/1999/04/06/06:11:38
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime AT docserver DOT cac DOT washington DOT edu for more info.
--KAA21220.923389190/alpha.netvision.net.il
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine DOT SUN DOT 3 DOT 91 DOT 990406120746 DOT 16726F AT is>
On Mon, 5 Apr 1999, Mark E. wrote:
> I configured texinfo from plain DOS once again but on another machine
> and again without problems. config.log reveals no problems. Both
> machines have Win95B and were run from its raw DOS mode.
More testing seems to indicate that the problem is triggered by using a
RAM disk. Both of the machines I tested this on point TMPDIR to a RAM
disk in plain DOS mode, but leave it on hard disk on Windows. Switching
to the hard disk in plain DOS solved the problem (or so it seems).
I'd be d*mned if I knew how is the RAM disk relevant here, but please try
to run the script this way. As far as I could see, with a RAM disk, even
"sh ./configure --help" triggers the error message from `cat'.
I use a shareware resizable RAM disk, so if you cannot reproduce the
problem with the standard driver supplied by M$, I can tell you where to
get the one I use.
I will also try to see what exactly does `cat' try to do when it fails
like that.
I'm now quite convinced that the problem lies somewhere in file
redirection code for ``here documents'' ("cat > foo <<EOF" etc.), and
that the binary nulls are some secondary effect caused by this. So
examining the code which handles here documents, especially if it changed
between v2.02 and v2.03, would be another approach.
Did you maybe replaced any libc.a modules (like the chroot stuff) when
you built the last binaries? If so, looking there might also be a good
idea.
--KAA21220.923389190/alpha.netvision.net.il--
- Raw text -