April Chin wrote: > > Attached is a small patch which introduces "oksh" to OS/Net. > > > > The patch adds "oksh", "roksh" and "pfoksh" to the package database (as > > hard link to /usr/bin/ksh), modifies getusershell.c to recognise these > > new shell names as login shells by default (and adds "nksh" as another > > option) and modifies wordexp.c to use "oksh" (this last item is a > > blocker which prevents the OpenSolaris-based distributions to ship ksh93 > > as /usr/bin/ksh right now (I have another patch for fixing the > > libc/wordexp() dependicy on the "old ksh" - but that requires > > libast/libshell to be present in the system (e.g. is a ToDo item once > > libast/libshell are present))). > > > > The only remaining item missing in the patch is to adjust the old > > Solaris ksh to recohnizse "roksh" the same was as "rksh" (e.g. > > restricted korn shell mode) and "pfoksh" the same as "pfksh" (profile > > mode korn shell). > > Unfortunately I cannot do it myself since the sources for the "old korn > > shell" are not available... ;-( > > > > April: Do you have time to act as sponsor for this patch, please ? > > A suggestion from a PSARC member was to keep /bin/ksh (Solaris's > ksh) as is, until it is replaced by ksh93, rather than introducing > these new obscure names for Solaris's ksh.
Which name and ksh versions do you mean ? Current Solaris ksh or ksh93 ? > Then when ksh93 becomes /bin/ksh, > to move Solaris's ksh to a separate package (not part of the main package > clusters). > > However, I think we still need to name Solaris's ksh something unique > from /bin/ksh (or at least move it to another directory), even if it > is moved to another package. Otherwise, ksh93 and the old Solaris ksh > cannot co-exist if that is desired while users are transitioning, > and would cause patching and upgrading problems. Well, I was thinking about the following scheme: - Scripts which need explicitly the old Solaris ksh behaviour use #!/bin/oksh - Scripts which need explicitly ksh93 use #!/bin/ksh93 - #!/bin/ksh can be either ksh93 or old Solaris ksh depending on which OpenSolaris distribution is used > So creating > /bin/oksh and the other links is still necessary. The idea behind the current patch was to add "oksh" for the "old" (=current) Solaris ksh and allow the various OpenSolaris distributions to safely introduce ksh93 as /bin/ksh. This is currently blocked by the problem that |libc::wordexp()| needs specifically the current Solaris ksh to work properly, making it impossible for them to switch to ksh93 - and the libraries provided by ksh93 (e.g. libast, libshell, etc.) are needed to fix |libc::wordexp()| so we are in a chicken&egg-like situation here (see http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-April/000227.html how I plan to fix that). > Questions: > - Do we need any links for /usr/xpg4/bin/sh? Once we've transitioned > to a standard-compliant ksh93, will there be any need for the old version > of the standard-compliant shell? AFAIK no, unless something like XPG6 demands a different shell behaviour (I doubt it as there is AFAIK no /usr/xpg6/bin/sh). > - Is it necessary to change wordexp() to use /usr/bin/oksh instead of > /usr/bin/ksh? Once ksh93 becomes /usr/bin/ksh, oksh may not be > installed into the Core Solaris cluster (see suggestion above), but > we could look at changing wordexp() to dlopen() of libshell.so or some other > method which uses ksh93. IMO this change is needed as a temporary solution (see http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-April/000227.html for the plan) to allow the OpenSolaris distributions to introduce ksh93 as /bin/ksh (otherwise stuff like inetd may blow-up badly). Once ksh93's libast is available in OS/Net we can use |libast::wordexp()| to fix |libc::wordexp()| permanently (and/or use libshell) - I just want to make sure there is a smooth transition. > I can sponsor the change and make the necessary changes to the closed > ksh source for you. Introducing the new links would likely be a > "fast-track" (simple) case for PSARC. Yes... but it may also be a good idea to think about backporting them to Solaris 10 and Solaris 9 since (for example) some products like Sun Studio are supported on more than one OS version. If these products then have scripts which require explicitly the old Solaris ksh it could be tricky to share them via NFS as /bin/oksh is not available on older versions (IMO the backport to older OS versions is very easy since it only involves creating the hard link from /bin/ksh to /bin/oksh). > Roland, I'll discuss more details offline. Ok... > Do you still have objections to introducing ksh93 as /bin/ksh93 rather > than nksh? No objections from my side. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
