mlink files (i.e., it is not even
called on the "real" file). Switching from find to finddepth seems to
fix this, but I really don't understand what's going on. Any pointers?
--
Adam Rosi-Kessel
http://adam.rosi-kessel.org
signature.asc
Description: OpenPGP digital signature
hink off the top
of my head why this is important, but it is a difference.
I think just as a matter of good programming style, if your program is
always suppose to background itself, you should have the program
background itself, rather than relying on the user to background it.
> On Sat, 2
in it but no real files, that
directory is not printed.
It seems to me that this is unrelated to "follow", which controls whether
symlinked *directories* are followed--in this case, it is a directory
full of symlinked files.
What am I missing?
--
Adam Rosi-Kessel
http://adam.rosi-kessel
definitely, and every three days run the
subroutine SendEmailToUsers. You obviously need to add a lot more to
have a sensible daemon: you'd at least want to check to make sure it was
not already running when you started it, and provide a system to shut the
daemon down.
--
Adam Rosi-Kessel
http://
You call KillAll with a process ID and it kills that process and all its
children. Can anyone suggest a better way to do this? Or does this seem
like a reasonable way to accomplish the goal?
--
Adam Rosi-Kessel
http://adam.rosi-kessel.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
On Tue, Aug 17, 2004 at 05:38:53PM -0400, Jim wrote:
> > My perl script forks and the child is subsequently replaced by another
> > (non-Perl) program with exec(). That child has its own subprocess.
> >
> > In response to certain events, the parent tries to kill the child (and
> > its children).
>
grandchildren pids without shelling out to ps?
- A good solution to the problem generally?
Using perl 5.8.4, Debian GNU/Linux unstable, 2.6.8-rc4 kernel.
Thanks very much for any tips or URLs.
--
Adam Rosi-Kessel
http://adam.rosi-kessel.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED
