Message-Id:	<199903081934.TAA52672@out5.ibm.net>
From:	"Mark E." <snowball3 AT usa DOT net>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date:	Mon, 8 Mar 1999 14:34:27 -0500
MIME-Version:	1.0
Subject:	Re: Bash 2.03 updated
References:	<199903041628 DOT QAA94472 AT out1 DOT ibm DOT net>
In-reply-to:	<Pine.SUN.3.91.990307132653.26544K-100000@is>
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/

- Raw text -