Brian Gupta wrote: > Why? My assumption, that this is for testing future changes in > Solaris. Without doing shell script execution speed testing, I don't > think this is a good idea.
We already did some performance testing. Except for startup time ksh93s+ is both faster than "bash" and "dash" for any real-world scripts (excluding the one-line "A=$$" thing earlier posted here; most of ksh93's performance comes from the builtin "bytecode" compiler, builtin commands, that entering subshells won't trigger a |fork()|+|exec()|, the advanced memory allocator etc.). > Keep in mind also that sh is also a smaller binary than ksh and bash. > (By over a factor of two in the case of ksh93, and a factor of 6 in > the case of bash). 1. We know ksh93 is big... it's the result of full POSIX standard conformance and the extra features built on top of it, e.g. floating-point math support (which needs libm.so.1), networking support (which needs libnsl.so.1 and libsocket.so.1) etc. 2. If you add stuff like fixes for multibyte handling (which means _multibyte_ handling and not "hardcoded" UTF-8 support) and full POSIX conformance then "dash" will grow a bit. 3. Please don't compare disk footprint - both bash and ksh93 don't perform well in this case because they drag larger amounts of strings around (in ksh93's case full manual pages) in their code which makes them look large. What really matters is the amount of code touched/executed for normal scripts, the memory footprint and the execution speed > (In Ubuntu they now are moving away from using bash as sh, and use a > shell called dash (the Debian Almquist Shell), which is a stripped > down, bourne shell like shell that aims to simply be a Posix shell > with a minimum of bells and whistles.) See http://mail.opensolaris.org/pipermail/indiana-discuss/2007-September/002165.html (section "[1]) about my opinion on this... IMO it would be a good idea to declare /usr/bin/sh an "interface" which points to a fully POSIX-conformant and CSI-enabled (e.g. is able to handle multibyte characters, even from non-UTF-8 encodings like ja_JP.PCK etc.) shell (which could be "ksh93", "bash" or "dash" (however the last two would require the same amount of work as we did for the ksh93-integration project, e.g. run the POSIX test suites and start fixing things (ksh93 was already very good as we started the project but it still took almost a year to kill all test suite failures and multibyte handling bugs... and I would expect that both "bash" and "dash" will require similar amounts of work))). Such a "declaration" would IMO solve most issues+bickering and would allow Indiana/OpenSolaris to switch to a different shell if something "better" comes out in the next 30 years. > Interesting reading regarding changing /bin/sh in a Linux distro and > the thoughts that went into it: https://wiki.ubuntu.com/DashAsBinSh > > More info on ash/dash http://en.wikipedia.org/wiki/Almquist_shell > > Keep in mind our sh is still actively being developed, with recent > work starting to improve execution speed via the inclusion of dtrace > probes. Erm... how do DTrace probes improve performance ? ---- Bye, Roland P.S.: Setting Reply-To: to [EMAIL PROTECTED] -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
