Joerg Schilling wrote: > "Garrett D'Amore" <garrett_damore at tadpole.com> wrote: > > I recently heard that there are plans to use isaexec to wrap ksh93. I > > think this is an incredibly bad idea. Especially given the > > microoptimizations that have been done lately to make ksh93 faster (e.g. > > the MMU page size adjustment.) > > > > The reason for this is that I understand that someday ksh93 will replace > > the default shell. I agree that having a POSIX shell be the default > > will be a good thing for the system, and I look forward to the day with > > ksh93 can fulfill this role. > > > > What concerns me, is that the extra time (2 milliseconds was a rough > > measurement done in one case) it takes to spawn a shell is going to have > > a negative impact on overall system performance if this becomes the > > default shell. > > > > The shell is forked/execed a _lot_. Consider builds of Solaris, where > > "make" spends almost all of its time execing the shell. > > I would take this as important argument for keeping the Bourne shell > for /bin/sh.
I strongly disagree. isaexec is only executed ONCE at startup and the usage of ONE single builtin (compared to fork()+exec() an external command) or "( ...)"-construct (which doesn't fork a shell child in ksh93) cancels this overhead complely out. Note that the original ARC fasttrack for ksh93 included /sbin/ksh93 which was a 32bit version only, mainly for two reasons: - It was thought that a startup script should not consume more than 2GB in any case. - The 64bit ksh93 was new and we weren't 100% sure whether it is completely functional (note: we did more testing in the meantime and it appears the 64bit ksh93 works Ok) If we ever do a migration of /bin/sh to ksh93 it may be nice to use the 64bit version if possible, maybe with or without the isaexec machinery in place. Both options would be Ok for /bin/sh. However /usr/bin/ksh should be a more capable shell and the isaexec is needed even on 64bit platforms to make sure that we can use the 32bit version on demand (for example when a ksh93 plugin library is only available as 32bit version). > Instead of replacing /bin/sh and breaking backwards compatibility, > it would help more to find a useful way to define how to directly refer to > the POSIX shell (and this way e.g. allowing to standardize on > #!<interpreter>). This would AFAIK be "/usr/xpg4/bin/sh", however this is useless because operating systems like Linux, *BSD and MacOSX do not have this file. Their /bin/sh is usually a POSIX shell by default (yes, I know... "bash"'s POSIX-conformace is more or less for /dev/null - but most stuff works...), including some further extensions beyond the POSIX shell spec which have become more or less a de-facto standard. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
