Date: Thu, 8 Apr 1999 11:16:03 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT usa DOT net>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Bash 2.03 updated March 22nd
In-Reply-To: <199904061447.OAA77006@out1.ibm.net>
Message-ID: <Pine.SUN.3.91.990408111523.29868J-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 6 Apr 1999, Mark E. wrote:

> The list of possible offenders is rather small, so one way or the other 
> this problem will be licked. However, it's not something I'll have the 
> time to look at until next week. 

Take your time; these problems are never solved in a hurry.

I think I now pretty much know what happens there.  The RAM disk has
nothing special to do with this, except that the cluster size on a RAM
disk is usually smaller.  I have found a way to reproduce this with a
hard disk as well.  Here's the drill:

  1.  Load the configure script into your favorite editor.
  2.  Find the part that prints the usage info when you invoke
      "configure --help".  It has a "cat << EOF" thing before it.
  3.  Double the size of the usage message by duplicating the text
      between "cat << EOF" and "EOF".
  4.  Exit the editor and run "sh ./configure --help".
  5.  If this works, go back to step 1.

Sooner or later, you will see the "cat: -: Access denied" message
coming out from this.  The exact point at which this happens depends
on the cluster size of your disk.

Windows 9X doesn't seem to have this problems, but on plain DOS it
happens after the text size (and thus the size of the temporary file
created by Bash) passes certain threshold.  Looking into `cat's code,
I found out that the problem comes from the code that actually reads
the (redirected) standard input, from the call to library function
`read'.  The weird thing is that an `fstat' call before that does
report the correct size of the file, so I don't have any guesses as to
what exactly goes wrong.

Comparing the code in Bash 2.02 and 2.03 that handles here documents
and file redirection in that case might provide some insight.

Let me know if you can reproduce this problem on your machine(s).