Casper.Dik at Sun.COM wrote: > > > >>> It's fine to make use of the ksh builtin support for various > > > >>> commands, but > > > >>> can we please learn from the problems that occurred when we > > > >>> changed sleep > > > >>> to be a builtin recently (e.g. 6793120) and instead create trivial > > > >>> wrapper > > > >>> *programs* that access the builtin functionality through libshell? > > > >> > > > >> I already have a fix (tested and queued for my sponsor) for CR > > > >> #6793120 > > > >> which does something similar as you've proposed... > > > > > > > > So there is a unique pid for each program and thus it can still be > > > > pkill'd? > > > > > > If so, and if this fix involves wrappers, Wouldn't we have lost the > > > "no fork/exec" advantage of having shell builtins in the first place, > > > right? > > > >My understanding is that the driving force is code sharing, not > >performance. If we are really concerned about the performance of the > >`sum' or `sleep' commands, something more fundamental is amiss. > > And if you start them as individual commands, there's no fork/exec > you can save. If you run ksh93, then you save the fork/exec.
Right... but in the case of OpenSolaris/Indiana /usr/bin/sh, /bin/sh, /sbin/sh, /usr/bin/ksh, /bin/ksh etc. (right now I am unsure about /usr/xpg4/bin/sh) are all links to /usr/bin/ksh93 and therefore a large chunk of default shells and system scripts benefit from the change. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
