fork/exec question

[Dave Saville]

In C terms a fork/exec of foo execing bar, where both are executables,
will show in ps two processes foo and bar and IIRC the parent pid of
bar will be foo's.

I have a perl script that forks and execs.

my $pid = fork()
die "Can't fork $!" if ! defined $pid;

unless ( $pid )
{
# child

exec "mplayer.........

}

print "$pid\n";

.....

Assume $pid is 123 If I run a ps I get

pid ppid prog
100 *** cmd
101 100 perl
123 100 perl
124 123 sh
125 124 sh
126 125 mplayer

Which is not what I would have expected.

I would have expected

100 *** cmd
101 100 perl
123 101 mplayer

Or very close. Of course this could be another OS/2 oddity

TIA

 

[Dave Saville]

Hi Ben

You're using 1-arg exec (tut). This is roughly equivalent to

Assumption based on an incomplete line of code But in ths case
true.

sub exec {
my ($cmd) = @_;

if ($cmd =~ /\Q$&*(){}[]'";\\|?<>~`\n/) {
exec "sh", "-c", $cmd;
}
else {
exec split " ", $cmd;
}
}

that is: if using a shell will make a difference, run it with the shell,
otherwise split on whitespace and run it directly. This is exactly the
same behaviour as system(), where it more closely matches what a C
programmer would expect, and it allows you to include shell redirections
in your command. (And, in fact, you must have done so, or perl wouldn't
have used the shell.)

No redirections in the command given to exec.

It's better in general to avoid this by using multi-arg system, which
always runs the command directly. Obviously in that case you have to do
any redirections yourself, between fork and exec; sometimes it's not
worth it.

We have established in the past, although possibly not in this NG,
that the OS/2 port often screws up passing parameters when not used in
1 arg mode.

But it still leaves the original question - why is there still perl
and a couple of sh's in the process chain? Or does perl exec never
actually call C exec and just fake it?

 

[Dave Saville]

In C terms a fork/exec of foo execing bar, where both are executables,
will show in ps two processes foo and bar and IIRC the parent pid of
bar will be foo's.

I have a perl script that forks and execs.

my $pid = fork()
die "Can't fork $!" if ! defined $pid;

unless ( $pid )
{
# child

exec "mplayer.........

}

print "$pid\n";

....

Assume $pid is 123 If I run a ps I get

pid ppid prog
100 *** cmd
101 100 perl
123 100 perl
124 123 sh
125 124 sh
126 125 mplayer

Which is not what I would have expected.

I would have expected

100 *** cmd
101 100 perl
123 101 mplayer

Or very close. Of course this could be another OS/2 oddity

Just run this on a *nix box and I get, almost, what I expected.

1493 1405 bash
1593 1493 perl
1594 1593 sh -c mplayer
1595 1594 mplayer

Ben has explained where the sh comes from ( 1 arg exec ) so I guees it
is an OS/2 funny.

 

[Peter J. Holzer]

[fork/exec on OS/2]

Assume $pid is 123 If I run a ps I get

pid ppid prog
100 *** cmd
101 100 perl
123 100 perl
124 123 sh
125 124 sh
126 125 mplayer

Which is not what I would have expected.

[...]
It's better in general to avoid this by using multi-arg system, which
always runs the command directly. Obviously in that case you have to do
any redirections yourself, between fork and exec; sometimes it's not
worth it.

We have established in the past, although possibly not in this NG,
that the OS/2 port often screws up passing parameters when not used in
1 arg mode.

But it still leaves the original question - why is there still perl
and a couple of sh's in the process chain? Or does perl exec never
actually call C exec and just fake it?

Does OS/2 even have an exec system call? I'm pretty sure it doesn't have
fork, so what ps shows you may not be real processes but threads.

hp

 

[Dave Saville]

On Sun, 8 Dec 2013 10:53:04 UTC, "Peter J. Holzer"

Does OS/2 even have an exec system call? I'm pretty sure it doesn't have
fork, so what ps shows you may not be real processes but threads.

It has both - but fork is *really* slow and inefficient compared to
*nix.

 

[Rainer Weikusat]

On Sun, 8 Dec 2013 10:53:04 UTC, "Peter J. Holzer"



It has both - but fork is *really* slow and inefficient compared to
*nix.

I haven't done anyting for or with OS/2 for a long time (17 - 18 years)
but I still remember that OS/2 has neither fork nor exec. The native
call is called DosExecPgm and perform this 'usual' create a new process
to run a different program functionality, cf

http://www.edm2.com/os2api/
http://www.edm2.com/os2api/Dos/DosExecPgm.html

EMX provides a fork call at the library level but it is not really
documented how this works. But considering the lack of OS-support, what
it will very likely do is use DosExecPgm to start a bootstrap program
making an actual of the process which called fork, similar to the way
fork used to work on UNIX(*) prior to virtual memory.

 

[Dave Saville]

I haven't done anyting for or with OS/2 for a long time (17 - 18 years)
but I still remember that OS/2 has neither fork nor exec. The native
call is called DosExecPgm and perform this 'usual' create a new process
to run a different program functionality, cf

http://www.edm2.com/os2api/
http://www.edm2.com/os2api/Dos/DosExecPgm.html

EMX provides a fork call at the library level but it is not really
documented how this works. But considering the lack of OS-support, what
it will very likely do is use DosExecPgm to start a bootstrap program
making an actual of the process which called fork, similar to the way
fork used to work on UNIX(*) prior to virtual memory.

Hi Rainer

Apologies - We now have a much later compiler than EMX, based on gcc
4.4.6 and I assumed it's LIBC had an exec(). Never tried it actually
but use fork a fair bit. A quick test on both EMX and the latter
yields the same - a duplicated process tree running the "execed"
program. You are correct about the way fork works - I said it was slow