Dan Mick wrote: > > The part (which I don't understand right now (after being more than 24h > > awake)) is that the |libshell::sh_tilde()| call is coming from a shell > > pattern (e.g. "~(Elr)(alias|unalias|command)") where the |getpwnam()| > > call is AFAIK completely useless... ;-( > > but this is so secondary to the actual problem, which is....what??? > > I have a small utilitarian program that I *need* to be small, utilitarian, and > have low system impact....and it's doing *NAMESERVICE* calls?
This is a bug and wasn't intended. > ok, sleep is maybe not so utilitarian for a machine in distress. > > kill? /usr/bin/kill was always a ksh88 script which we now switched over to ksh93. The problem is the '~' in the wrapper which caused the |getpwnam()| calls and it was never intended to do any name service calls in this case (and IMO this needs to be fixed in ksh93 since doing |getpwnam()| just because a shell pattern contains a '~' is a (performance killer)^2). > I'm sorry, but I'm going to have to open this discussion again: I just don't > understand how moving these simple, sometimes critical, commandline utilities > to > ksh scripts is even close to reasonable. Most of these tools were already ksh88 scripts (e.g. /usr/bin/kill, /usr/bin/test etc.). The point for "sleep"&co. was to re-use existing, maintained code instead of maintaining two seperate codelines (e.g. one in usr/src/cmd/sleep/ and the AST/ksh93 "sleep" version) which have to be kept in sync all the time. The case for "sleep" is currently easy (but won't be that easy in the future since more stuff gets added like alternative signal handling, suffixes for values etc.) but there are cases like "cut"/"paste"/"join"/"tail"/etc. where it won't be that easy to maintain two seperate codelines (at least I don't have the strength to keep two totally different codelines in sync (nor was the old commands&&utilities team willing to do that in the long-term and the favor was (and AFAIK still is) to have only one set of modern+maintained+64bit clean tools (that's why we selected the AT&T AST tools long ago))). Another issue is (what I already tried to explain in tools-discuss@ to Edward&co): The existing ksh88+commands codebase had nearly 20 years to mature. We're now trying something new here (which includes: Completely new codebase) and really cannot predict all problems but we're trying it hard to address any issues as fast as possible and make new test suite modules, too (to avoid that we have to address any problems more than once). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
