Dan Price wrote: > On Wed 23 Aug 2006 at 10:50PM, Mike Kupfer wrote: [snip] > > I'm not sure everyone on the list will follow that argument, so I want > > to back up for a moment and fill in a couple details, because I think > > it's a good point. (If it's obvious to you what Roland's talking about, > > feel free to ignore the rest of this email.) > > > > ksh93 comes with a large set of built-in commands. The advantage of > > having so many built-ins is performance. But we want to avoid code > > duplication, which means structuring the built-ins and the standalone > > binaries to use common code. This will be more of a hassle if ksh93 is > > in SFW, because it probably would involve exposing private interfaces > > across a consolidation boundary. > > I didn't fully follow it, so thanks for the clarification, Mike. > > I guess while I'm a fan of having an up-to-date ksh implementation, > I'm unsure of the architectural direction of implementing various > other system commands in terms of it. > > To what degree are we making architectural decisions about a large > swath of our base userland utilities here?
We don't make this kind of decision now, e.g. we will NOT do that for the first putback. We'll come back when we're done - however some low-hanging fruits like getting /usr/bin/sleep and /usr/bin/pwd to use the libshell builtin versions would be easy (and is somewhere high on my ToDo list) and would even fix the problems that the current Solaris "sleep" version has no floating-point support (e.g. % /usr/bin/sleep 0.1 # doesn't work outside ksh93 right now) and that /usr/bin/pwd misses the very common "-P" and "-L" options (e.g. those two commands would be the "pathfinders" for the later work)... > I agree that if we're going to go replace wc, etc. with things from > ksh, then there may well be a compelling argument to bringing this > stuff into ON, since the level of mixing will be high. > > But then... wouldn't we be tying the implementation of wc, etc. > to the *private interfaces* of something which originates externally? > Is that architecturally sound? Would PSARC accept this (I ask because > I honestly don't know the answer). I think this is OK since we would move to one single source code base where the AST and Solaris commands have been syncronised in both source and functionality. That's why the Sun layers are currently looking into the details how Sun/OpenSolaris.org can contribute OS/Net bits back to AT&T under their own license (or dual-license it etc. - I am not a laywer and don't know how thos works). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
