Date: Sun, 7 Mar 1999 13:27:17 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: Bash 2.03 updated In-Reply-To: <199903041628.QAA94472@out1.ibm.net> Message-ID: 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 Thu, 4 Mar 1999, Mark E. wrote: > I've update the packages to fix the crash that was introduced in the > 2.02.1 -> 2.03 upgrade. Almost there, I think. I have two gripes and two observations. Gripe no.1: When I set PATH_SEPERATOR=:, it seems like the behavior is unaffected by the value of PATH_EXPAND. To wit: on a DOS machine, the subsidiary programs invoked by Bash, including Bash itself and Make, get the PATH in the /dev/c/foo:/dev/d/bar form, which of course causes many failures (Make fails to run commands, Bash doesn't find external programs, etc.). I tried the same on Windows, and there PATH is *always* expanded, no matter how PATH_EXPAND is set (even if I set LFN=n). I'm not sure what's going on here. Gripe no.2: Ctrl-C causes Bash to abort with a traceback, as if I pressed Ctrl-BREAK. This is in contrast to usual operation of DJGPP programs, where Ctrl-C just exits with no traceback. One problem with this, besides the aesthetics, is that the traceback causes important information to scroll off the screen. Could we have the usual behavior back, please? Observation no.1: When Bash is aborted with Ctrl-C, the registers' dump prints strange data for the FS selector: it has a very low base address (e.g. 00004110) and a 64KB limit (0000ffff). Is this normal, and if so, how does this happen? Observation no.2: This version of Bash is considerably slower than 1.14.7 for the same script. I measured the time used by both to run a typical configure script, and the old version is almost twice as fast as the new one. In particular, the new version sometimes ``thinks'' for prolonged periods of time (mostly about 1 second, but I saw it stop for 5 seconds a couple of times, which is A LOT for a P166 in plain DOS mode). These pauses seem to be not entirely deterministic, so maybe they have some kind of garbage collection going on (I don't have the sources to look). Pretty annoying, if you ask me. It would be swell, if you could look into this problem. Can somebody compare these two versions on Unix, so we could at least know if the problem is specific to the DJGPP port or not?