First red flag:

                  $b =~m/^\s*\w+\s+(\d+)\s+/o;
                  my $b_pid = $1;
[download]

Oh, and that applies a few lines later too. At least you're consistently wrong.

Second red flag:

   my @args = ("kill", "-9", $2);
[download]

First yellow flag, back to the earlier code snippet:

m/^\s*\w+\s+(\d+)\s+/o
[download]

Second yellow flag... that sort screams for a Schwartzian Transform.

Third yellow flag: Perl has a kill function. Why not use it instead of system'ing out?

Conclusion: other than the bit about the Schwartzian Transform, the knowledge you are missing is contained within Learning Perl, which suggests that you read that book very soon.

Never never never use kill -9 on a process, unless that process has resisted prior attempts to die via kill 1, 2, and 15.

Is that general advice for all processes, or is it only for programs that you don't know, that haven't failed to die properly earlier, etc?

I.e. if I have a program whose processes consistently fail to die properly, should I still kill it with 1, 2, and 15 before 9?

/J

if I have a program whose processes consistently fail to die properly, should I still kill it with 1, 2, and 15 before 9

If you have a program like that, you should rewrite it! {grin}

But yes, that's the applicable rule. "kill -9" is always the "last resort" kill.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

this script is for use exclusively under Unix, or Unix like, operating systems (if the system command ps -eaf could be rewritten in pure Perl, then the OS restriction could be lifted)

Unfortunately, one of the issues that differ significantly across versions of unix and unix-like operating systems is the behavior of "ps". In particular, the options you use in this script will work on any "SysV" style of unix (e.g. Solaris), and might work on linux (if you're using linux, you know better than me), but it won't work on any BSD style (e.g. (free|open|net)bsd, or the bsd-based macosx), because the latter uses a completely different set of option flags.

It turns out there are a couple ways around this:

• Have some logic that looks at $^O and sets option flags for "ps" accordingly (update: unless you do this very carefully, you may still have problems because the output formats will be very different for BSD vs. SysV), or
• use Unix::Process, which allows you to get just the information you want from "/bin/ps", by way of the abbreviations assigned to the different possible output fields ("pid", "ppid", "vsz", etc). It still runs /bin/ps to do its work, and the different versions of "ps" are not 100% consistent in the field names (e.g. Solaris "ps" uses "comm" and "args" where BSD uses just "command"), but several important names are common to both versions -- whereas the command-line options are not. So you still might need to do different stuff depending on the value of $^O, but some things are more likely to be the same for all unixen.

This post is actually in reply to both previous comments (merlyn's and graff's).

There is nothing quite like posting your code to an open forum to make you write better code...  :)    Thank you for your comments.

The o in m//o was something I pulled from Programming Perl, 3^rd edition.  It is supposed to give a hint to the regexp compiler that the regexp only needs to be compiled once.  I suppose the same thing could be achieved with qr//.  Also, good catch on blindly using $1.

I can see how, in a general purpose setting, -9ing a process would be a Very Bad Thing.  This is the first thing on the bug list.  As for systeming out for kill instead of using the built-in, does the built-in allow you access to the error codes?  Also, because the code was already system dependent (ps -eaf), I figured why not add some more (sort of like using $& and friends in a regexp).  The world in which I work/play/code consists of Solaris, Irix, and Fedora Core 2.  So within my admittedly small world, the code works.

I will be updating the above code over the next day or two (as time permits) to fix your observations of what is wrong.  BTW, does anyone know where there is a list of all the strings $^O could contain?

the regexp only needs to be compiled once

You gotta read the rest of the text right around there. I'd quote it, but I don't have my camel with me (I'm on a trip). But the perlop manpage says:

               PATTERN may contain variables, which will be interpolat
+ed (and
               the pattern recompiled) every time the pattern search i
+s evalu-
               ated, except for when the delimiter is a single quote. 
+ (Note
               that $(, $), and $| are not interpolated because they l
+ook like
               end-of-string tests.)  If you want such a pattern to be
+ com-
               piled only once, add a "/o" after the trailing delimite
+r.  This
               avoids expensive run-time recompilations, and is useful
+ when
               the value you are interpolating won't change over the l
+ife of
               the script.  However, mentioning "/o" constitutes a pro
+mise
               that you won't change the variables in the pattern.  If
+ you
               change them, Perl won't even notice.  See also
               "qr/STRING/imosx".
[download]

Thus, /o is useful only when there are variables in the pattern. And you had no patterns with variables!

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I'm mildly suprised that no-one caught the problem in the following line:
  $process = qr/\s+(?:\d+[:])+?\d+\s+.*?$ARGV[0].*?\s*$/;

Because I'm using user input in a regexp, I should have done one of the following:

  # use \Q and \E
  $process = qr/\s+(?:\d+[:])+?\d+\s+.*?\Q$ARGV[0]\E.*?\s*$/;
  # or enclose in an eval
  eval { $process = qr/\s+(?:\d+[:])+?\d+\s+.*?$ARGV[0].*?\s*$/; };
  if($@) { ... }
[download]