fork/exec question

Discussion in 'Perl Misc' started by Dave Saville, Dec 7, 2013.

  1. Dave Saville

    Dave Saville Guest

    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
    --
    Regards
    Dave Saville
     
    Dave Saville, Dec 7, 2013
    #1
    1. Advertising

  2. Dave Saville

    Dave Saville Guest

    On Sun, 8 Dec 2013 05:56:58 UTC, Ben Morrow <> wrote:

    Hi Ben

    >
    > Quoth "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.

    >
    > 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?
    --
    Regards
    Dave Saville
     
    Dave Saville, Dec 8, 2013
    #2
    1. Advertising

  3. Dave Saville

    Dave Saville Guest

    On Sat, 7 Dec 2013 16:16:07 UTC, "Dave Saville" <>
    wrote:

    > 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.
    --
    Regards
    Dave Saville
     
    Dave Saville, Dec 8, 2013
    #3
  4. On 2013-12-08 10:27, Dave Saville <> wrote:
    > On Sun, 8 Dec 2013 05:56:58 UTC, Ben Morrow <> wrote:
    >> Quoth "Dave Saville" <>:


    [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


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaƟt. -- Ralph Babel
     
    Peter J. Holzer, Dec 8, 2013
    #4
  5. Dave Saville

    Dave Saville Guest

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

    <Snip>
    > 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.
    --
    Regards
    Dave Saville
     
    Dave Saville, Dec 8, 2013
    #5
  6. "Dave Saville" <> writes:
    > On Sun, 8 Dec 2013 10:53:04 UTC, "Peter J. Holzer"
    > <> wrote:
    >
    > <Snip>
    >> 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.


    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.
     
    Rainer Weikusat, Dec 8, 2013
    #6
  7. Dave Saville

    Dave Saville Guest

    On Sun, 8 Dec 2013 18:16:22 UTC, Rainer Weikusat
    <> wrote:

    > "Dave Saville" <> writes:
    > > On Sun, 8 Dec 2013 10:53:04 UTC, "Peter J. Holzer"
    > > <> wrote:
    > >
    > > <Snip>
    > >> 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.

    >
    > 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
    :)
    --
    Regards
    Dave Saville
     
    Dave Saville, Dec 9, 2013
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patrick
    Replies:
    1
    Views:
    527
  2. Hoegje
    Replies:
    2
    Views:
    22,552
    Gianni Mariani
    Dec 5, 2003
  3. Benoit Dejean

    fork, exec, and disown

    Benoit Dejean, Feb 8, 2004, in forum: Python
    Replies:
    4
    Views:
    956
    Benoit Dejean
    Feb 9, 2004
  4. Ajay Bakhshi
    Replies:
    0
    Views:
    411
    Ajay Bakhshi
    May 3, 2004
  5. Eric Snow

    os.fork and pty.fork

    Eric Snow, Jan 8, 2009, in forum: Python
    Replies:
    0
    Views:
    574
    Eric Snow
    Jan 8, 2009
Loading...

Share This Page