William James wrote:
>
> On 3/15/07, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> > Sivakumar Shanmugasundaram wrote:
> > > Roland Mainz wrote:
> > > > Sivakumar Shanmugasundaram wrote:
> > [snip]
> > > > See http://www.opensolaris.org/os/project/ksh93-integration/downloads/
> > > > for the download page. The latest tarballs is from 2006-12-14 (based on
> > > > ast-ksh93.2006-12-07) but I am going to update this once the new ast-ksh
> > > > sources are out.
> > > >
> > > > Alternatively you can try to build ksh93 from our OS/Net prototype tree
> > > > as described in
> > > > http://www.opensolaris.org/os/project/ksh93-integration/downloads/2006-12-14/
> > > > , those sources are based on ast-ksh.2007-01-11 (e.g. newer than the
> > > > latest binary tarball on the download page).
> > >
> > > Great. I have renamed the ksh93 binary to 'ksh' (along with rksh and
> > > under amd64/sparv9) and running it as my default shell in S11 x64 and
> > > Sparc
> > > I like it.
> >
> > Uhm... you are aware that this may break SMF's inetd services (inetd
> > uses |libc::wordexp()| which uses a secret switch in Solaris's
> > /usr/bin/ksh to do the word expansion. Unfortunately ksh93 does not
> > support the "secret switch"-hack which causes |libc::wordexp()| to fail
> > and this renderes inetd defunct. We have a solution in the
> > ksh93-integration prototype004 tree which replaces the original
> > |libc::wordexp()| function with a version which uses ksh93 instead...
> > but that requires to replace your libc.so.1 libraries with the patched
> > version...) ?
>
> Why can't you just compile the ksh93 wordexp() for all libc versions?
Erm, because it would...
1. require ksh93 to be available
2. it would break backwards-compatibity. Problem is that the current
|libc::wordexp()| has two codepaths, one "normal" which uses
"/usr/bin/ksh" and a "XPG4" codepath which uses "/usr/xpg4/bin/sh" for
word expansion. Switching to ksh93 would make |libc::wordexp()| always
behave like the XPG4 codepath - and that would break "compatiblity".
The tricky question is: How "worse" would be the loss of
backwards-compatibilty. "/usr/bin/ksh" and "/usr/xpg4/bin/sh" have AFAIK
identical ways to expand words and ksh93 behaves in almost all ways like
"/usr/xpg4/bin/sh" ... which raises the question whether this will
affect any real-world applications (I doubt it... it will IMO be very
difficult if not impossible to craft a simple testcase to figure out the
difference between the normal and XPG4 codepaths for |libc::wordexp()|
since the shells ("/usr/bin/ksh", "/usr/xpg4/bin/sh") are siblings,
build from the same sources).
> Or set an environment variable to tell applications to use the ksh93
> code?
Using an environment variable would not help (how would you pass this
variable to all processes, even to those where the environment gets
"cleaned" with something like $ env - mycmd # ?).
In theory something like /etc/default/_libc could be used (which could
contain a switch like WORDEXP_USE_KSH93=true/false) ... but I guess that
would count as "API" and would require an ARC case (or not... maybe we
could declare it a "debug API") or worse (thanks to [2] above).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
