> 1. The issue with startup time is known but at least > 50% is unavoidable > since ksh93 does some mandatory i18n/l10n setup which > the Bourne shell > doesn't do (which results in some issues with > multibyte character > handling). If you would start fixing the multibyte > handling bugs in the > Bourne shell then you'll quickly end-up with the same > startup penalty as > in ksh93.
You know the shell well and are probably right about this. However, I believe most calls to /bin/sh are for trivial non-interactive scripts (say set a couple variables and exec something else) that probably don't need all this, and it is sad to suffer from a delay in this case. 1) would it be possible for ksh93 to postpone some of this heavy setup until it detects that it is needed? (how could it detect it?) 2) would you recommend that trivial shell scripts explicitly use an interpreter /bin/sh-light instead of /bin/sh (harder for calls to system(3C))? That would be a pain. 3) what general techniques exist to reduce startup time? Having one initialized instance of ksh93 and letting all the next ones simply fork from this one seems way too heavy a mechanism for a shell (besides, different instances of the shell may not share all the initialization parameters). Same thing for caching some data in a file in the HOME directory of the user (although it can make sense for other parts of the shell, like tab-completion). There may not be anything useful that can be done... This message posted from opensolaris.org
