allbery@ncoast.UUCP (Brandon Allbery) (07/27/86)
Expires: Quoted from <212@amc.UUCP> ["Re: csh-script to run a job after an existing job terminates"], by stan@amc.UUCP (Stan Tazuma)... +--------------- | In article <515@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: | >DESCRIPTION: | >after: a procedure that waits until a particular running process terminates, | > then initiates a new process. This runs under csh, but should be | > easily translatable to bsh or ksh. | > | I think it's a useful tool, but there are simpler ways to do it (at | least under a BSD Unix (which includes the Ultrix you're using)). | Here's a program I came up with a while back. It's called waitp. | It has the same args. as "after". | ------------waitp.c------------ | For AT&T Unix versions, getpgrp() doesn't behave in the above way (waitp.c). | The AT&T ps command can be used to look at a specific process, though | using a different ps argument than above. +--------------- I have another method; it works everywhere except that under System V it doesn't work to see if a process has exited and should be waited upon (this doesn't apply to an ``after'' program anyway): -------- #! /bin/sh while kill -0 ${1-?}; do sleep ${2-60} done -------- The C version is just as trivial. Note that kill -0 isn't documented in V7 or System III... then again, V7 didn't have getpgrp() that I saw, so neither method will work. ++Brandon -- ---------------- /--/ Brandon S. Allbery UUCP: / / /|\/ Tridelta Industries, Inc. decvax!cwruecmp!ncoast! ---- -------- /-++ 7350 Corporate Blvd. tdi2!brandon / / /---, /--/ Mentor, Ohio 44060 PHONE: (home) / / / / / / -- HOME -- +1 216 974 9210 / / / / / / 6615 Center St. Apt. A1-105 ARPA: ncoast!allbery% ---- /----~ /--/ Mentor, Ohio 44060-4101 case.CSNET@csnet-relay ------------------------------------------------------------------------------- Space -- The Final Frontier
peters@cubsvax.UUCP (Peter S. Shenkin) (07/31/86)
In article <ncoast.1325> allbery@ncoast.UUCP (Brandon Allbery) writes: >I have another method; it works everywhere except that under System V it >doesn't work to see if a process has exited and should be waited upon (this >doesn't apply to an ``after'' program anyway): >-------- >#! /bin/sh >while kill -0 ${1-?}; do > sleep ${2-60} >done >-------- >The C version is just as trivial.... This doesn't work under ULTRIX or, I would guess, 4.2. "kill -0" returns the error message, "bad signal number" regardless of the existence of the process. In addition to what's been posted on the net, I've received a number of mail followups to my original posting, most of contained good ideas for improving the routine. Hopefully I'll get around to putting together and posting a "master version" eventually... but for now, a change I've made in the version I'm using is to replace the use of both sed and awk with a simple "ps x pid#", followed by a test of $status. If the process existed, $status is 0; else, 1. This is better than another suggestion, involving the line, "ps x | fgrep pid# | fgrep -v fgrep", for three reasons. First of all, it's simpler. Second, the fgrep method will often find strings you're not looking for: like job number 22299 when you're looking for job 222 (I suppose you could specify -w in the first fgrep). Third, "after" will always find itself; that is, if pid# 3998 was the command "after 3997 script1", the "after" line will be found by the fgrep string, and script1 will never execute. To take care of this, you have to pipe through an "fgrep -v -w after"..... and now that I've seen all this I wonder if there is not yet another tiger lurking in these woods.... The "kill -0" idea was sent to me by mail... was it by you, Brandon? (I'm too lazy to look right now!) Whoever it was, I tried to reply by mail, but the letter bounced. But this all concerns the general question, "what is the most efficient portable UNIX method for checking whether a process exists, given a pid#". In fact, it would be good enough to answer four questions: what is the most efficient way to do this: 1) in bsd systems, from the shell 2) in bsd systems, from a C-program 3) in at&t systems, from the shell 4) in at&t systems, from a C-program. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA