Message-Id: <199903081934.TAA52672@out5.ibm.net> From: "Mark E." To: Eli Zaretskii , djgpp-workers AT delorie DOT com Date: Mon, 8 Mar 1999 14:34:27 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Bash 2.03 updated References: <199903041628 DOT QAA94472 AT out1 DOT ibm DOT net> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01d) Reply-To: djgpp-workers AT delorie DOT com > 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'm not sure> what's going on here. It is a weird one. Apparently, the path variables that get their paths expanded in the environment that is passed on to child programs gets fixed up by luck more than design. It leads to the weird ways expansion fails that you mention. I can trigger the bug by setting PATH_SEPARATOR=: and PATH_EXPAND=Y before starting Bash, but setting them inside Bash wouldn't trigger the bug. Setting PATH_SEPARATOR=: and not PATH_EXPAND before running Bash wouldn't trigger the bug either. The problem was the variables weren't being expanded as they were being copied to the child's environment, but they were being expanded in another part of the code if they happened to be in the right place in the environment. > > Gripe no.2: Ctrl-C causes Bash to abort with a traceback, as if I > pressed Ctrl-BREAK. At least in the Bash produced with Gripe #1 fixed, I don't see this problem either in plain DOS or under Windows. > Observation no.2: This version of Bash is considerably slower than > 1.14.7 for the same script. I have a P166 too and haven't really noticed a slow down. Then again, I tend to wonder off and do something else while configure does its thing. Some possibilities: 1) Use of GNU malloc provided by Bash. It may or may not be slower than libc's malloc, but GNU's malloc will abort with a message if I try to free something twice whereas libc's malloc doesn't warn. Sometime before release, I'll reconfigure Bash to use the native malloc. Or it may be... 2) No optimization. Some of the early Bash 2.02.1 binaries were built with -O2, but debugging with rhgdb proved annoying because the highlight bar kept jumping around, so I stopped using "-O2". It resulted in some bloat (20-40K), so perhaps that's part of the slowdown. Mark --- Mark Elbrecht snowball3 AT usa DOT net http://members.xoom.com/snowball3/