Date: Tue, 6 Apr 1999 12:09:40 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: djgpp-workers AT delorie DOT com
Subject: Re: Bash 2.03 updated March 22nd
Message-ID: <Pine.SUN.3.91.990406120746.16726D-100000@is>
MIME-Version: 1.0
Content-Type: MULTIPART/REPORT; REPORT-TYPE=delivery-status; BOUNDARY="KAA21220.923389190/alpha.netvision.net.il"
Content-ID: <Pine DOT SUN DOT 3 DOT 91 DOT 990406120746 DOT 16726E AT is>
Reply-To: djgpp-workers AT delorie DOT com

  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--