Re: Bash-4.0-rc1 available for FTP

2009-02-02 Thread Nicolas

bash_completion is too slow because it does strange things: it parses
itself because it wants to emulate the behavior of "-o plusdirs".
See 
https://bugzilla.redhat.com/show_bug.cgi?id=479936

for a preliminary patch.


Thanks for pointing this out. This would indeed be a significant 
improvement!


Apparently, bash-completion is very active at the moment. They are 
currently trying to fix as many bugs as possible, and will then optimize 
bash-completion for Bash 3.x.


Nicolas




Re: Bash-4.0-rc1 available for FTP

2009-02-02 Thread Dan Nicolaescu
Nicolas  writes:

  > Hello,
  > 
  > I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the
  > results.
  > My computer is a Pentium M (running at 600 MHz for the test), running Linux
  > 2.6.26 with libc6 version 2.7 and Debian bash-completion version 20080705.
  > The figures are averages over 100 tests.
  > 
  > Bash 3.2, without bash malloc:
  >  * eval `dircolors`: 0.636s
  >  * source /etc/bash_completion: 0.721s
  > 
  > Bash 4.0, with bash malloc:
  >  * eval `dircolors`: 0.385s
  >  * source /etc/bash_completion: 41.651s (around 93% of the time is spent in
  > function find_entry of lib/malloc/table.c)
  > 
  > Bash 4.0, without bash malloc:
  >  * eval `dircolors`: 0.132s
  >  * source /etc/bash_completion: 0.703s

bash_completion is too slow because it does strange things: it parses
itself because it wants to emulate the behavior of "-o plusdirs".
See 
https://bugzilla.redhat.com/show_bug.cgi?id=479936
for a preliminary patch.




Re: Bash-4.0-rc1 available for FTP

2009-01-31 Thread Nicolas
> Bash versions other than `release' are built with extensive extra arena
> and allocation checking enabled in the bash malloc.

Thanks for pointing this out.

Here are the new results:

Bash 4.0, with bash malloc:
 * eval `dircolors`: 0.138s
 * source /etc/bash_completion: 0.735s

Bash 4.0, without bash malloc:
 * eval `dircolors`: 0.135s (slightly slower than with debugging on, I
checked several times to be sure. This is very surprising...)
 * source /etc/bash_completion: 0.702s

Without bash malloc, the results are close to the results with
debugging on. The results with bash malloc are far better now, but
still slightly behind those with libc malloc, on my computer.

In addition, in builtins/evalstring.c, line 271, an itrace call is not
enclosed between #if defined (DEBUG) and #endif, as it should be.

With my computer at normal speed (with the 'ondemand' governor),
starting a new shell (and running my .bashrc) now takes around 0.4s,
while it took 0.6s with Bash 3.2. This is enough to feel a difference!

Nicolas




Re: Bash-4.0-rc1 available for FTP

2009-01-31 Thread Chet Ramey
Nicolas wrote:
> Hello,
> 
> I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the
> results.

Thanks.

> Bash 4.0, with bash malloc:
>  * eval `dircolors`: 0.385s
>  * source /etc/bash_completion: 41.651s (around 93% of the time is spent in
> function find_entry of lib/malloc/table.c)

Bash versions other than `release' are built with extensive extra arena
and allocation checking enabled in the bash malloc.  The `find_entry'
function is the primary interface to look up the record kept for each
allocation.  As you can imagine, bash takes quite a performance hit when
this kind of allocation debugging is enabled.

If the results are acceptable with allocation tracing and debugging on,
they should be even better in the release version.  If you'd like to
experiment right now, you can recompile after disabling the `DEBUG' and
`MALLOC_DEBUG' defines in Makefile.  (Or you can just rebuild with
`make DEBUG= MALLOC_DEBUG='.)


> We notice that on my computer, libc6's malloc is definitively faster than
> Bash's malloc.

Let's not decide that just yet. :-)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/




Re: Bash-4.0-rc1 available for FTP

2009-01-31 Thread Nicolas
Hello,

I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the
results.
My computer is a Pentium M (running at 600 MHz for the test), running Linux
2.6.26 with libc6 version 2.7 and Debian bash-completion version 20080705.
The figures are averages over 100 tests.

Bash 3.2, without bash malloc:
 * eval `dircolors`: 0.636s
 * source /etc/bash_completion: 0.721s

Bash 4.0, with bash malloc:
 * eval `dircolors`: 0.385s
 * source /etc/bash_completion: 41.651s (around 93% of the time is spent in
function find_entry of lib/malloc/table.c)

Bash 4.0, without bash malloc:
 * eval `dircolors`: 0.132s
 * source /etc/bash_completion: 0.703s

We notice that on my computer, libc6's malloc is definitively faster than
Bash's malloc.
More interesting is the fact that the various improvements to command
substitution have dramatically reduced its execution time (eval `dircolors`
is now 4.8 times faster!).

Thank you very much for this wonderful new version of Bash!
Nicolas


Re: Bash-4.0-rc1 available for FTP

2009-01-12 Thread Matthew Woehlke

Chet Ramey wrote:

Matthew Woehlke wrote:

Chet Ramey wrote:

f.  Changed behavior so the shell now acts as if it received an interrupt
when a pipeline is killed by SIGINT while executing a list.

Does this mean that
$ sleep 60 ; do-something
...will no longer run 'do-something' when ctrl-C'd?


Yes.


Cool :-). Thanks for that enhancement!

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Your eyes are weary from staring at the CRT. You feel sleepy. Notice how 
restful it is to watch the cursor blink. Close your eyes. The opinions 
stated above are yours. You cannot imagine why you ever felt otherwise.

  -- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)





Re: Bash-4.0-rc1 available for FTP

2009-01-12 Thread Chet Ramey
Matthew Woehlke wrote:
> Chet Ramey wrote:
>> f.  Changed behavior so the shell now acts as if it received an interrupt
>> when a pipeline is killed by SIGINT while executing a list.
> 
> Does this mean that
> $ sleep 60 ; do-something
> ...will no longer run 'do-something' when ctrl-C'd?

Yes.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/




Re: Bash-4.0-rc1 available for FTP

2009-01-12 Thread Matthew Woehlke

Chet Ramey wrote:

f.  Changed behavior so the shell now acts as if it received an interrupt
when a pipeline is killed by SIGINT while executing a list.


Does this mean that
$ sleep 60 ; do-something
...will no longer run 'do-something' when ctrl-C'd?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Your eyes are weary from staring at the CRT. You feel sleepy. Notice how 
restful it is to watch the cursor blink. Close your eyes. The opinions 
stated above are yours. You cannot imagine why you ever felt otherwise.

  -- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)





Bash-4.0-rc1 available for FTP

2009-01-12 Thread Chet Ramey
The first public release candidate of bash-4.0 is now available with the URL

ftp://ftp.cwru.edu/pub/bash/bash-4.0-rc1.tar.gz

This tar file does not include the formatted documentation (you
should be able to generate it yourself).

This release fixes the remaining serious bugs in the bash version 3 branch
and introduces significant new features.

The most notable new features are associative arrays, improvements to the
programmable completion functionality, case-modifying word expansions,
co-processes, support for the `**' special glob pattern, and additions to
the shell syntax and redirections.  The shell has been changed to be more
rigorous about parsing commands inside command substitutions, fixing one
piece of Posix non-compliance.

`bashbug' may be used to report bugs with this version.

As always, thanks for your help.

Chet

+== CHANGES ==+
This document details the changes between this version, bash-4.0-rc1,
and the previous version, bash-4.0-beta2.

1.  Changes to Bash

a.  Fixed a bug that caused parsing errors when a $()-style command
substitution was follwed immediately by a quoted newline.

b.  Fixed a bug that caused extended shell globbing patterns beginning with
`*(' to not work when used with pattern substitution word expansions.
 
--
This document details the changes between this version, bash-4.0-beta2,
and the previous version, bash-4.0-beta.

1.  Changes to Bash

a.  Fixed a bug that caused failed word expansions to set $? but not
PIPESTATUS.

b.  Changed filename completion to quote the tilde in a filename with a
leading tilde that exists in the current directory.

c.  Fixed a bug that caused a file descriptor leak when performing
redirections attached to a compound command.

d.  Fixed a bug that caused expansions of $@ and $* to not exit the shell if
the -u option was enabled and there were no posititional parameters.

e.  Fixed a bug that resulted in bash not terminating immediately if a
terminating signal was received while performing output.

f.  Fixed a bug that caused the shell to crash after creating 256 process
substitutions during word completion.

2.  Changes to Readline

a.  Fixed a bug that caused redisplay errors when using prompts with invisible
characters and numeric arguments to a command in a multibyte locale.

b.  Fixed a bug that caused redisplay errors when using prompts with invisible
characters spanning more than two physical screen lines.

--
This document details the changes between this version, bash-4.0-beta,
and the previous version, bash-4.0-alpha.

1.  Changes to Bash

a.  Fixed a typo that caused a variable to be used before initialization
while parsing Posix-style command substitutions.

b.  Fixed a bug that caused stray ^? when the expansion of a parameter used
as part of a pattern removal expansion is empty, but part of a non-
empty string.

c.  Fixed a bug that could cause strings not converted to numbers by strtol
to be treated as if the conversion had been successful.

d.  The `return' builtin now accepts no options and requires a `--' before
a negative return value, as Posix requires.

e.  Fixed a bug that caused local variables to be created with the empty
string for a value rather than no value.

f.  Changed behavior so the shell now acts as if it received an interrupt
when a pipeline is killed by SIGINT while executing a list.

g.  Fixed a bug that caused `declare var' and `typeset var' to initialize
`var' to the empty string.

h.  Changed `bind' builtin to print a warning but proceed if invoked when
line editing is not active.

i.  Fixed a bug that caused the shell to exit when the `errexit' option is
set and a command in a pipeline returns a non-zero exit status.

j.  Fixed a bug that caused the shell to not run the exit trap in a command
run with `bash -c' under some circumstances.

k.  Fixed a bug that caused parser errors to occasionally not set $? when
running commands with `eval'.

l.  Fixed a bug that caused stray control characters when evaluating compound
array assignments containing $'\x7f' escapes.

m.  Fixed a bug that caused redirections involving file descriptor 10 as the
target to behave incorrectly.

n.  Fixed a bug that could cause memory to be freed multiple times when
assigning to COMP_WORDBREAKS.

o.  Fixed a bug that could cause NULL pointer dereferences when COMP_WORDBREAKS
was unset.

2.  Changes to Readline

3.  New Features in Bash

a.  A value of 0 for the -t option to `read' now returns success if there is
input available to be read from the specified file descriptor.

b.  CDPATH and GLOBIGNORE are ignored when the shell is running in privileged
mode.

c.  New bindable readline functions shell-forward-word and shell-backward-word,
which m