David Morano writes: > + the latest KSH appear as /sbin/sh (statically linked if desired)
No, completely static linking isn't possible on Solaris nor would it be desirable if it were possible. But having /sbin/sh updated at some point in time would be. "/sbin" doesn't mean "static." > + no /usr/bin/ksh93 on the system; why do I need that if I have > /usr/bin/ksh as the latest KSH already? No, that likely won't be possible. Once added to the system, we'll have to retain that pointer forever, because there will likely be no plausible justification for breaking scripts that were once written to do #!/usr/bin/ksh93. It's a wart, perhaps, but one that'll very likely continue. > + finally, it looks like KSH best belongs in ON (OS/Net); but that isn't > really the concern from a user's perspective That one is still murky. If there are no highly-fluid dependencies on the rest of ON (i.e., vast tracts of private interfaces that change frequently), then there's nothing that binds ksh to ON. It would seem to have a much greater affinity to SFW, as that's where it's generally acceptable to have your own non-ON build style, use non-default compilers if you want, do testing right in the middle of the build process (rather than in the test gate where it belongs), and so on. But assuming those dependencies aren't there, this is no longer an architectural issue, and it doesn't matter in the context of this thread. > If one wants /sbin/sh to be KSH, and for it to be dynamically linked > (doesn't really have to be as far as I am concerned), then > libast.so > libcmd.so > others > should be in /lib for early boot-up time while /usr isn't mounted. Indeed. But if /sbin/sh isn't KSH, none of that is needed _today_. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
