Roland Mainz writes: > > As it stands, the project proposed doesn't actually fix this problem. > > No, and I didn't propose it as this putback and the code we already > wrote targets at a backport for Solaris 10 - the inclusion of > |libc::wordexp()| in this case would make a backport tricker because we > would have to seperate the |libc::wordexp()| issue somehow.
It's hard to tell, because that's not the case before us. But I'll go along with that. > > "In theory" doesn't quite work here. If the scope of this project is > > widened to encompass replacing wordexp with something less horrible, > > and if the right answer for handling embedded shell expansion in > > wordexp parsing is to exec ksh93, then you've got at least one > > possibly good argument to put ksh93 (or at least some portion of it) > > in the root file system. > > The problem is that this needs to be ARC'ed because ksh93 will enforce > XPG4 behaviour which is currently only used for XPG4-compilant > applications. In practice the difference is non-existant (since we are > talking only about the word expansion in ksh vs. POSIX shell which is > virtually identical in all imagineable production cases&&usage (yes, I > know - it is always possible to craft something which exposes a > difference. That's an excellent argument for saying that there's no reason to avoid using the new ksh93 to handle wordexp, perhaps even in a patch. > But the consumers of |libc::wordexp()| do not do that in > real life)) but the old implementation made the difference where one > version uses /usr/bin/ksh and the other uses /usr/xpg4/bin/sh (which is > /usr/bin/ksh hacked with lots of |#ifdef|s until it worked more or less > exactly as described in the POSIX specs). I think that epithet might underestimate the difficulty of actually passing those conformance test suites. In any event, this is all beside the point. You can't use wordexp as a reason to put these libraries in root because you're not actually delivering the wordexp bits in this project. -- 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
