Gavin Maltby wrote: > James Carlson wrote: > > As for the answer to the question, I think that this latest problem > > ought to be the last straw: if the fix works and can be quickly tested > > in all the scenarios that have broken, then ok. If it fails anywhere > > for any reason, then yank it until there is a well-tested fix. > > Enough's enough. ksh93 isn't the only project in the gate. > > If we fix instead of revert to the old-style sleep implementation > then in addition to testing against the above I'd have a whole > lot more confidence if the execution of the new sleep were > carefully analysed with tools such as truss and/or dtrace. > > If I truss an old-style sleep I get a whole 35 lines of output, > with nothing more suspicious than the expected linker > activity, a few mmap, getcontext, getpid, brk etc. > > If I truss the ksh93 sleep I get 260 lines (not bad actually). > The first 35 are the isaexec of /usr/bin/ksh93 finding > /usr/bin/amd64/ksh93 in my case then the expected library > activity (libshell, libcmd, libast, libm).
Erm... it looks you're debugging an old version then. The new codebase after http://mail.opensolaris.org/pipermail/onnv-notify/2009-February/008582.html uses libshell directly and no longer any isaexec stuff or /usr/bin/ksh93. > Finally > we open /bin/sleep but next I see a search through my > PATH for a file .paths (so sleep depends on NFS servers now) That will be fixed - see below for the webrev... > and shortly thereafter we open the name_service_door > (alarm bells to current discussion). That will by http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6807179_002/ , including a test suite module which explicitly tests for this condition to make sure we never see this again. > That won't eliminate issues such as the execname issue for pgrep, That was already fixed by http://mail.opensolaris.org/pipermail/onnv-notify/2009-February/008582.html > but we can confirm it's being about as honest and clean as > a shell script can be. Slightly offtopic: Do you know _any_ other issues which need to be fixed except those listed above (I really like to kill all bugs/complains now in "one go") ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)