[indiana-discuss] Moving forward with a replacement for /sbin/sh ... / was: Re: [caiman-discuss] Need your input on safemodeboot archive in Indiana

[Bruno Jargot]

Roland, are you telling us that /bin/sh could be updated to ksh93 today?

On Dec 5, 2007 5:50 AM, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> David.Comay at Sun.COM wrote:
> [snip]
> > I know that Roland has some ideas on moving forward in this area and
> > though I haven't had the time to review these ideas personally, perhaps
> > working with him would be a good start.
>
> Erm... technically most (or better: _all_ of the work which I can do
> alone has been done (see below for the remaning bits)) of the work has
> already been done and the upcoming ksh93-integration update will
> integrate further changes+fixes based on the feedback we got in the last
> half year...
> ... AFAIK the only remaning "blocker" ToDo item (before large-scale
> testing/deployment as /sbin/sh ([1]) in a distribution like Indiana)
> would be to create something like /sbin/ksh93 and move the ksh93
> libraries (e.g. { libshell, libcmd, libdll, libsum and libast } to the
> root filesystem as part of an ARC case. In theory we could do this with
> the upcoming ksh93-integration update ARC case but we need _support_ for
> a "consumer" for this (the original draft for PSARC/2006/550 proposed
> /sbin/ksh93 but this was removed because we lacked such a consumer who
> simply said "we need it [=/sbin/ksh93]" ... and we still have this
> chicken&&egg problem (e.g. without having /sbin/ksh93 around the
> important consumers can't use ksh93 and will therefore use other
> solutions (or ignore simply ignore bugs (e.g. see the discussion in
> sfwnv-discuss@ with SMF scripts not being able to detach processes)) but
> without consumers we can't do the move...) ... ;-( ) - otherwise we're
> just stuck in the chicken&&egg situation forever...
>
> [1]=See
> http://mail.opensolaris.org/pipermail/indiana-discuss/2007-August/002079.html
> , part 3 ('Which shell should replace the "original" Bourne shell as
> /sbin/sh ?') - IMO /sbin/sh should be defined to be a "POSIX shell",
> e.g. /sbin/sh should be more like an "abstract interface" which
> implements the POSIX shell standard (erm... better wording is needed in
> this case... ;-/ ). If someone needs any features beyond the feature set
> defined in the standard a different interpreter (e.g. /sbin/ksh93)
> should be used. This leaves the door open for future (POSIX conformant)
> shells (this definition tries to ensure that we don't run into same
> "update /sbin/sh"-trouble again in 10 or 20 years).
>
> ----
>
> Bye,
> Roland
>
> --
>   __ .  . __
>  (o.\ \/ /.o) roland.mainz at nrubsig.org
>   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>   /O /==\ O\  TEL +49 641 7950090
>  (;O/ \/ \O;)
>



-- 
Bruno