open3 "sh -c" problem with pipes or redirect

[Guest]

I have a perl programming that has been running for the last 10 or so
years. It manages other processes, capturing all outputs into a
common logfile and killing dormant processes (no output) after a given
amount of time. The user can print processes up or down as needed.
It utilizes the Event.pm module and it works fine. Now I I have the
need to either run a process that utilizes a pipe "x | y" or setup two
separate processes and redirect stdin/stdout to use a named pipe ("x

name_pipe" and "y <name_pipe"). In either case, the open3 call uses

a "sh -c" to execute the command. The pid that is returned is the pid
of the shell command and when I attempt to terminate the process only
the shell command is killed, not the children.

I suspect the answer is to modify the stdin/stdout file handles as
needed and pass those to open3. Is this the correct solution or is
there another way?

Currently, this is running on Solaris 8 & 10, sparc and Intel. There
is no need for portability to windows.

Thanx.

Brad

 

[C.DeRykus]

I have a perl programming that has been running for the last 10 or so
years.  It manages other processes, capturing all outputs into a
common logfile and killing dormant processes (no output) after a given
amount of time.  The user can print processes up or down as needed.
It utilizes the Event.pm module and it works fine.  Now I I have the
need to either run a process that utilizes a pipe "x | y" or setup two
separate processes and redirect stdin/stdout to use a named pipe ("x>name_pipe" and "y <name_pipe").  In either case, the open3 call uses

a "sh -c" to execute the command.  The pid that is returned is the pid
of the shell command and when I attempt to terminate the process only
the shell command is killed, not the children.

I suspect the answer is to modify the stdin/stdout file handles as
needed and pass those to open3.  Is this the correct solution or is
there another way?

Currently, this is running on Solaris 8 & 10, sparc and Intel.  There
is no need for portability to windows.

Since portability wouldn't be an issue, you could try a negative
signal to target an entire process group. See perldoc -f kill or
perldoc perlipc for details.

 

[Guest]

Since portability wouldn't be an issue, you could try a negative
signal to target an entire process group. See perldoc -f kill or
perldoc perlipc for details.

Charles,
thank you for the input. Unfortunately I did try that and it
failed. I also tried to setup a process group using setpgrp() but I
did not get that to work correctly either. I may have being doing
something wrong so that is also a possibility.

Brad