Xref: utzoo comp.unix.wizards:23971 comp.unix.programmer:981 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!orc!inews!hopi!bhoughto From: bhoughto@hopi.intel.com (Blair P. Houghton) Newsgroups: comp.unix.wizards,comp.unix.programmer Subject: Re: deamon help Message-ID: <2304@inews.intel.com> Date: 5 Feb 91 21:50:31 GMT References: <594@edpmgt.UUCP> Sender: news@inews.intel.com Organization: Intel Corp, Chandler, AZ Lines: 39 In article bzs@world.std.com (Barry Shein) writes: >Just write a shell script loop which uses awk to suck out the TIME >field of the procs as reported by ps and see if it's changing or not. Gack. Scripts for daemons. Barry, you should be ashamed. :-) Write it in C and use popen(3). (Use YACC for the parsing, if you want it done to a crisp). (Uh-oh. My BSD is showing. Does SysV know popen?) A stronger reason to use C is that ps(1) often runs fields together; it can also munge columnar justification. You'll have to detect and work around those situations. (If you can characterize the various forms of run-together fields, lex(1) can tokenize them together and then yacc(1) can parse them apart). For example (output of "ps alx | egrep 'TIME|foo'"): F UID PID PPID CP PRI NI ADDR SZ RSS WCHAN STAT TT TIME COMMAND 94080012010 11236 11235255 96 41eba211194 9660 R N pa143:58 (foo) b0000013092 17289 244 7 1 017232 41 21 be598 S 10 0:00 egrep TIME| PID 17829 is fine. PID 11236 is a mess. awk(1) and perl(1) would barf up gnodes at this. (Those of you who smell challenge, smell aright.) >For a problem like this I'll bet you a nickel crafting the whole thing >in C using /dev/kmem etc will not be much faster than the above >described script, and will take a week to get right instead of 30 minutes. Better, use popen(3) and top(1). Top usually gets the data much faster than ps. Why? Who knows? Could be anything from superior skills among public-domain software developers to abuse of /dev/null. --Blair "My every keyword is copyright someone else, these days..."