Stefan Teleman wrote: > Roland Mainz wrote: > > Stefan Teleman wrote: > >> Roland Mainz wrote: > >>> or "you > >>> must come-up with 'solid, unbendable proof' that the changes do not > >>> break anything" (<--- nasty comment of the day: Right now some stuff > >>> delivered via SFWNV (like "bash") doesn't even pass it's own test suite > >>> in the way how it's build in SFWNV)) and may even be impossible for > >>> people without access to matching hardware. > >> i'm updating bash to 4.0. soon-ish. > > > > Erm... could we please sync our work ? I've been working on that since a > > longer time now (trying to dig-out all issues and getting it more or > > less in feature-sync with the ksh93-integration work (e.g. see > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/bash4/wishlist.txt)) > > and try to get the ARC case done in two weeks... > > could you please explain why do we need a 64-bit bash ? > > i know it's "cool". does it do anything that a 32-bit largefile-aware > bash doesn't ?
1. bash supports (like ksh93) binary plugins 2. bash4 now supports associative arrays which can grow quite large (OkOk, bash4 lacks compound variables and variable tree support (which was the main reason why we got a 64bit ksh93 (since we knew that variable trees with several GB are used on production systems (the largest core dump observed in 2004 on a production system was 30GB, most of this was in a single tree variable)))) and I don't see the reason of "artifically" limiting the array size on systems with enougth memory 3. A bash4 compiled as AMD64 code runs faster than a 32bit x86 bash4 version > i think the bash demo stuff belongs in /contrib. Erm... /usr/demo/bash/ would be my preference... ---- Bye, Roland P.S.: Setting Reply-To: to shell-discuss at opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
