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). 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) and shortly thereafter we open the name_service_door (alarm bells to current discussion). That won't eliminate issues such as the execname issue for pgrep, but we can confirm it's being about as honest and clean as a shell script can be. Gavin
