Newbie Question about multiple system calls within loops

Discussion in 'C Programming' started by student.matt@gmail.com, Jun 26, 2008.

  1. Guest

    ok i am trying to solve this little problem i have my program waits
    for the 1st system() call to finish before starting the next i will
    just throw an example of what i mean out

    in this example it waits for the 1st kedit to be closed before it
    opens the second

    #include <stdio.h>
    #include <stdlib.h>
    int main()
    {

    int count = 0;

    while(count <= 5)
    {
    system("kedit");
    count++;
    }

    return 0;

    }


    what i would like to figure out is to make all 5 kedits open at once,
    once agian i am fairly new i am just trying to figure out basic
    concepts and in this one why exactly it waits for the 1st call to
    finish before making the second
    , Jun 26, 2008
    #1
    1. Advertising

  2. rahul Guest

    On Jun 26, 8:01 am, wrote:
    > ok i am trying to solve this little problem i have my program waits
    > for the 1st system() call to finish before starting the next i will
    > just throw an example of what i mean out


    You should not be using the term system call when what you actually
    mean is invoking the system library function.
    > in this example it waits for the 1st kedit to be closed before it
    > opens the second

    Did you consider looking at the documentation for system() ?

    NAME
    system - execute a shell command

    SYNOPSIS
    #include <stdlib.h>

    int system(const char *command);

    DESCRIPTION
    system() executes a command specified in command by calling /
    bin/sh -c command, and returns after the
    command has been completed. During execution of the command,
    SIGCHLD will be blocked, and SIGINT and
    SIGQUIT will be ignored.

    I am posting Linux man pages but the basic idea holds true for any
    platform. system() will not return until and unless the command you
    have invoked through system is completed.
    rahul, Jun 26, 2008
    #2
    1. Advertising

  3. schrieb:

    > what i would like to figure out is to make all 5 kedits open at once,
    > once agian i am fairly new i am just trying to figure out basic
    > concepts and in this one why exactly it waits for the 1st call to
    > finish before making the second


    Have a look at fork/exec.

    Note that this question better belongs to
    comp.os.linux.development.system (or the system you're working with).
    You're probably gonna get yelled at here because this group deals with
    the C language (not the system programming in C).

    Regards,
    Johannes

    --
    "Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
    reicht zu wissen, daß andere es besser können und andere es auch
    besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
    in de.sci.electronics <47fa8447$0$11545$>
    Johannes Bauer, Jun 26, 2008
    #3
  4. wrote:
    > ok i am trying to solve this little problem i have my program waits
    > for the 1st system() call to finish before starting the next i will
    > just throw an example of what i mean out
    >
    > in this example it waits for the 1st kedit to be closed before it
    > opens the second
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    > int main()
    > {
    >
    > int count = 0;
    >
    > while(count <= 5)
    > {
    > system("kedit");
    > count++;
    > }
    >
    > return 0;
    >
    > }
    >
    >
    > what i would like to figure out is to make all 5 kedits open at once,
    > once agian i am fairly new i am just trying to figure out basic
    > concepts and in this one why exactly it waits for the 1st call to
    > finish before making the second


    By definition, system() does not return until the command has been
    completed.

    Your system may have some way to "detach" a shell command so that
    system() will return immediately (e.g. "kedit &"), but that's inherently
    non-portable. Likewise, it may have other ways to do the same thing
    without system(), e.g. fork()/exec(), but those are also non-portable.

    If you are willing to restrict your program to POSIX environments, then
    you may wish to take advantage of some of the additional functionality
    available from the POSIX (not C) standard, but that's off-topic here.

    S
    Stephen Sprunk, Jun 26, 2008
    #4
  5. Guest

    On Jun 26, 6:02 pm, Stephen Sprunk <> wrote:
    > wrote:
    > > ok i am trying to solve this little problem i have my program waits
    > > for the 1st system() call to finish before starting the next i will
    > > just throw an example of what i mean out

    >
    > > in this example it waits for the 1st kedit to be closed before it
    > > opens the second

    >
    > > #include <stdio.h>
    > > #include <stdlib.h>
    > > int main()
    > > {

    >
    > > int count = 0;

    >
    > > while(count <= 5)
    > > {
    > > system("kedit");
    > > count++;
    > > }

    >
    > > return 0;

    >
    > > }

    >
    > > what i would like to figure out is to make all 5 kedits open at once,
    > > once agian i am fairly new i am just trying to figure out basic
    > > concepts and in this one why exactly it waits for the 1st call to
    > > finish before making the second

    >
    > By definition, system() does not return until the command has been
    > completed.

    By whose definition? Certainly not ISO 9899:1999's.

    > Your system may have some way to "detach" a shell command so that
    > system() will return immediately (e.g. "kedit &"), but that's inherently
    > non-portable. Likewise, it may have other ways to do the same thing

    system("kedit &") is as portable as system("kedit")

    > without system(), e.g. fork()/exec(), but those are also non-portable.
    >
    > If you are willing to restrict your program to POSIX environments, then
    > you may wish to take advantage of some of the additional functionality
    > available from the POSIX (not C) standard, but that's off-topic here.

    Agreed. It's topical in comp.unix.programmer, so OP can try that group
    for POSIX questions.
    , Jun 26, 2008
    #5
  6. Guest

    On Jun 26, 5:34 pm, wrote:
    > On Jun 26, 6:02 pm, Stephen Sprunk <> wrote:
    >
    > > wrote:
    > > > ok i am trying to solve this little problem i have my program waits
    > > > for the 1st system() call to finish before starting the next i will
    > > > just throw an example of what i mean out

    >
    > > > in this example it waits for the 1st kedit to be closed before it
    > > > opens the second

    >
    > > > #include <stdio.h>
    > > > #include <stdlib.h>
    > > > int main()
    > > > {

    >
    > > > int count = 0;

    >
    > > > while(count <= 5)
    > > > {
    > > > system("kedit");
    > > > count++;
    > > > }

    >
    > > > return 0;

    >
    > > > }

    >
    > > > what i would like to figure out is to make all 5 kedits open at once,
    > > > once agian i am fairly new i am just trying to figure out basic
    > > > concepts and in this one why exactly it waits for the 1st call to
    > > > finish before making the second

    >
    > > By definition, system() does not return until the command has been
    > > completed.

    >
    > By whose definition? Certainly not ISO 9899:1999's.
    >
    > > Your system may have some way to "detach" a shell command so that
    > > system() will return immediately (e.g. "kedit &"), but that's inherently
    > > non-portable. Likewise, it may have other ways to do the same thing

    >
    > system("kedit &") is as portable as system("kedit")
    >
    > > without system(), e.g. fork()/exec(), but those are also non-portable.

    >
    > > If you are willing to restrict your program to POSIX environments, then
    > > you may wish to take advantage of some of the additional functionality
    > > available from the POSIX (not C) standard, but that's off-topic here.

    >
    > Agreed. It's topical in comp.unix.programmer, so OP can try that group
    > for POSIX questions.


    Thanks for all the responses sorry for posting here, but the
    system("kedit &"); did work read the man on system() little bit better
    understanding of whats going on. i looked up 10 different
    documentations on fork/exec it seems a little complicated just yet

    but thanks for the help
    , Jun 26, 2008
    #6
  7. On 26 Jun 2008 at 19:13, wrote:
    >> > wrote:
    >> > > what i would like to figure out is to make all 5 kedits open at once,

    >
    > Thanks for all the responses sorry for posting here, but the
    > system("kedit &"); did work read the man on system() little bit better
    > understanding of whats going on. i looked up 10 different
    > documentations on fork/exec it seems a little complicated just yet


    It's really not all that complicated. Here's a simple example that
    addresses your original question:


    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/types.h>

    int main(void)
    {
    pid_t pid;
    int count;
    for(count=0; count<5; count++) {
    pid=fork();
    if (pid==0) {
    /* child process */
    execlp("kedit", "kedit", (char *) NULL);
    perror("exec failure");
    exit(1);
    }
    }
    return 0;
    }
    Antoninus Twink, Jun 26, 2008
    #7
  8. Chad Guest

    On Jun 26, 12:28 pm, Antoninus Twink <> wrote:
    > On 26 Jun 2008 at 19:13, wrote:
    >
    > >> > wrote:
    > >> > > what i would like to figure out is to make all 5 kedits open at once,

    >
    > > Thanks for all the responses sorry for posting here, but the
    > > system("kedit &"); did work read the man on system() little bit better
    > > understanding of whats going on. i looked up 10 different
    > > documentations on fork/exec it seems a little complicated just yet

    >
    > It's really not all that complicated. Here's a simple example that
    > addresses your original question:
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <unistd.h>
    > #include <sys/types.h>
    >
    > int main(void)
    > {
    >   pid_t pid;
    >   int count;
    >   for(count=0; count<5; count++) {
    >     pid=fork();
    >     if (pid==0) {
    >       /* child process */
    >       execlp("kedit", "kedit", (char *) NULL);


    Maybe I misunderstood section 8.10 in the book "Advance Programming in
    the Unix Environment" by Stevens and Rago, but I believe
    (char *)NULL actually creates undefined behavior when it's passed to
    the exec() family.

    >       perror("exec failure");
    >       exit(1);
    >     }
    >   }
    >   return 0;
    >

    I thought it was supposed to be exit(0) and not

    return 0

    in this case.
    >
    >
    > }- Hide quoted text -
    >
    Chad, Jun 27, 2008
    #8
  9. Chad Guest

    On Jun 26, 12:28 pm, Antoninus Twink <> wrote:
    > On 26 Jun 2008 at 19:13, wrote:
    >
    > >> > wrote:
    > >> > > what i would like to figure out is to make all 5 kedits open at once,

    >
    > > Thanks for all the responses sorry for posting here, but the
    > > system("kedit &"); did work read the man on system() little bit better
    > > understanding of whats going on. i looked up 10 different
    > > documentations on fork/exec it seems a little complicated just yet

    >
    > It's really not all that complicated. Here's a simple example that
    > addresses your original question:
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <unistd.h>
    > #include <sys/types.h>
    >
    > int main(void)
    > {
    >   pid_t pid;
    >   int count;
    >   for(count=0; count<5; count++) {
    >     pid=fork();
    >     if (pid==0) {
    >       /* child process */
    >       execlp("kedit", "kedit", (char *) NULL);
    >       perror("exec failure");
    >       exit(1);
    >     }
    >   }
    >   return 0;
    >
    >
    >
    > }- Hide quoted text -
    >
    > - Show quoted text -


    And off course this is again off topic. So not only does this troll
    fail to understand that this is a C forum, but this person writes
    questionable simple *nix code.
    Chad, Jun 27, 2008
    #9
  10. Chad <> writes:
    > On Jun 26, 12:28 pm, Antoninus Twink <> wrote:

    [...]
    > > #include <stdio.h>
    > > #include <stdlib.h>
    > > #include <unistd.h>
    > > #include <sys/types.h>
    > >
    > > int main(void)
    > > {
    > > pid_t pid;
    > > int count;
    > > for(count=0; count<5; count++) {
    > > pid=fork();
    > > if (pid==0) {
    > > /* child process */
    > > execlp("kedit", "kedit", (char *) NULL);

    >
    > Maybe I misunderstood section 8.10 in the book "Advance Programming in
    > the Unix Environment" by Stevens and Rago, but I believe
    > (char *)NULL actually creates undefined behavior when it's passed to
    > the exec() family.


    <OT>No, it's correct; it's used to mark the end of the arguments.</OT>

    > > perror("exec failure");
    > > exit(1);
    > > }
    > > }
    > > return 0;
    > >

    > I thought it was supposed to be exit(0) and not
    >
    > return 0
    >
    > in this case.


    Within main(), ``exit(0)'' and ``return 0'' are almost exactly
    equivalent.

    exit(1) is non-portable (the only portable exit arguments are 0,
    EXIT_SUCCESS, and EXIT_FAILURE), but the code is non-portable anyway.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 27, 2008
    #10
  11. On Thu, 26 Jun 2008 17:20:50 -0700 (PDT),
    Chad <> wrote:
    > On Jun 26, 12:28 pm, Antoninus Twink <> wrote:
    >> On 26 Jun 2008 at 19:13, wrote:


    >>       execlp("kedit", "kedit", (char *) NULL);

    >
    > Maybe I misunderstood section 8.10 in the book "Advance Programming in
    > the Unix Environment" by Stevens and Rago, but I believe
    > (char *)NULL actually creates undefined behavior when it's passed to
    > the exec() family.


    \begin{offtopic}

    I think you've got it the wrong way around. The last argument in the
    variable list _has_ to be cast to char *.

    This is, of course, not a standard C function, but a POSIX one, and
    therefore it'd be better to discuss its interface on
    comp.unix.programmer, rather than here. It is probably a good idea to
    check http://www.opengroup.org/onlinepubs/000095399/functions/exec.html
    and your system's man page before you ask the people there.

    \end{offtopic}

    Martien
    --
    |
    Martien Verbruggen | It's not what we don't know that hurts us,
    | it's what we know for certain that just ain't
    | so. -- Mark Twain
    Martien Verbruggen, Jun 27, 2008
    #11
  12. On 27 Jun 2008 at 0:48, Martien Verbruggen wrote:
    > Chad <> wrote:
    >> On Jun 26, 12:28 pm, Antoninus Twink <> wrote:
    >>>       execlp("kedit", "kedit", (char *) NULL);

    >>
    >> Maybe I misunderstood section 8.10 in the book "Advance Programming in
    >> the Unix Environment" by Stevens and Rago, but I believe
    >> (char *)NULL actually creates undefined behavior when it's passed to
    >> the exec() family.

    >
    > \begin{offtopic}


    ?? Are you serious? Surely even the most anal topicality zealot would
    accept that how to pass arguments to a variadic function is topical in
    clc? I guess not.

    > I think you've got it the wrong way around. The last argument in the
    > variable list _has_ to be cast to char *.


    To elaborate on this for the benefit of "Chad", who prefers to insult
    other people rather than learn from them: this isn't just language
    fussiness, but is necessary in the real world too.

    NULL is a macro, commonly defined either as (void *)0, or just as plain
    0. In the first case, there's no problem. In the second case, because by
    definition there's no prototype for the arguments in the variable part
    of a variadic function, if the preprocessor expands NULL to plain 0,
    then the compiler will apply the default promotions and pass 0 as an
    int. Things will go wrong in the common situation where int is 32 bits,
    but pointers are 64 bits.
    Antoninus Twink, Jun 27, 2008
    #12
  13. Antoninus Twink wrote:
    > On 27 Jun 2008 at 0:48, Martien Verbruggen wrote:
    >> Chad <> wrote:
    >>> On Jun 26, 12:28 pm, Antoninus Twink <> wrote:
    >>>> execlp("kedit", "kedit", (char *) NULL);
    >>> Maybe I misunderstood section 8.10 in the book "Advance Programming in
    >>> the Unix Environment" by Stevens and Rago, but I believe
    >>> (char *)NULL actually creates undefined behavior when it's passed to
    >>> the exec() family.

    >> \begin{offtopic}

    >
    > ?? Are you serious? Surely even the most anal topicality zealot would
    > accept that how to pass arguments to a variadic function is topical in
    > clc? I guess not.


    No prototype (and other documentation) for execlp() was listed, so in
    theory it's off-topic here. If you had said "my system has a variadic
    function named execlp(), and the last parameter must be of type (char *)
    [or (void *)]", folks not familiar with POSIX would be able to comment.

    >> I think you've got it the wrong way around. The last argument in the
    >> variable list _has_ to be cast to char *.

    >
    > To elaborate on this for the benefit of "Chad", who prefers to insult
    > other people rather than learn from them: this isn't just language
    > fussiness, but is necessary in the real world too.
    >
    > NULL is a macro, commonly defined either as (void *)0, or just as plain
    > 0. In the first case, there's no problem. In the second case, because by
    > definition there's no prototype for the arguments in the variable part
    > of a variadic function, if the preprocessor expands NULL to plain 0,
    > then the compiler will apply the default promotions and pass 0 as an
    > int. Things will go wrong in the common situation where int is 32 bits,
    > but pointers are 64 bits.


    Or in the case of processors that pass pointers and integers in
    different registers...

    However, I would expect that in either of those cases, the
    implementation's definition of NULL would be of the "(void *)0" form,
    not the "0" form, specifically to eliminate problems like this. Since
    the representations of (void *) and (char *) must be the same, it would
    take a rather perverse implementation (e.g. the DS9k) to pass them
    differently to variadic functions.

    S
    Stephen Sprunk, Jun 29, 2008
    #13
  14. Antoninus Twink wrote:
    > On 26 Jun 2008 at 19:13, wrote:
    >>>> wrote:
    >>>>> what i would like to figure out is to make all 5 kedits open at once,

    >> Thanks for all the responses sorry for posting here, but the
    >> system("kedit &"); did work read the man on system() little bit better
    >> understanding of whats going on. i looked up 10 different
    >> documentations on fork/exec it seems a little complicated just yet

    >
    > It's really not all that complicated. Here's a simple example that
    > addresses your original question:
    >
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <unistd.h>
    > #include <sys/types.h>
    >
    > int main(void)
    > {
    > pid_t pid;
    > int count;
    > for(count=0; count<5; count++) {
    > pid=fork();
    > if (pid==0) {
    > /* child process */
    > execlp("kedit", "kedit", (char *) NULL);
    > perror("exec failure");
    > exit(1);
    > }
    > }
    > return 0;
    > }
    >


    <OT>
    If you're having trouble figuring out what's going on above, consider
    this primitive (and buggy) implementation of system():

    int system(const char *command) {
    pid_t pid = fork();
    if (!pid) {
    execlp(command, (char *)NULL);
    return -1;
    } else {
    return waitpid(pid, NULL, 0);
    }
    }

    Since the OP was looking to remove the waitpid() part of system(), the
    most logical answer is to use fork()/exec() directly.

    Once you wrap your head around the concepts that fork() returns twice
    and exec() never returns (assuming everything works properly), the whole
    process is rather obvious.
    </OT>

    S
    Stephen Sprunk, Jun 29, 2008
    #14
  15. CBFalconer Guest

    Chad wrote:
    > Antoninus Twink <> wrote:
    >

    .... snip ...
    >
    >> It's really not all that complicated. Here's a simple example
    >> that addresses your original question:

    >

    .... snip twink gubris ...
    >
    > And off course this is again off topic. So not only does this
    > troll fail to understand that this is a C forum, but this person
    > writes questionable simple *nix code.


    That troll understands very well. Its only objective is to disrupt
    the newsgroup. Just PLONK it. To do so, get a real newsreader,
    such as Thunderbird, and abandon google.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
    CBFalconer, Jun 29, 2008
    #15
  16. santosh Guest

    CBFalconer wrote:

    > Chad wrote:
    >> Antoninus Twink <> wrote:
    >>

    > ... snip ...
    >>
    >>> It's really not all that complicated. Here's a simple example
    >>> that addresses your original question:

    >>

    > ... snip twink gubris ...


    I suppose you meant hubris here?

    <snip>
    santosh, Jun 29, 2008
    #16
  17. In article <>,
    Tony Mc <> wrote:
    >On Sun, 29 Jun 2008 08:56:57 +0530, santosh <>
    >wrote:


    >> I suppose you meant hubris here?


    >gubris is the GNU implementation of ISO standard hubris.


    Not quite: it is the GNU implementation of something -like-
    ISO standard hubris, but with extensions that
    violate constraints in the ISO standard hubris, with the
    extensions turned on by default (under the excuse that
    since gubris does not claim to be ISO standard hubris, the
    ISO standard's constraints have no authority over gubris.)
    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
    Walter Roberson, Jun 30, 2008
    #17
  18. santosh Guest

    Walter Roberson wrote:

    > In article <>,
    > Tony Mc <> wrote:
    >>On Sun, 29 Jun 2008 08:56:57 +0530, santosh <>
    >>wrote:

    >
    >>> I suppose you meant hubris here?

    >
    >>gubris is the GNU implementation of ISO standard hubris.

    >
    > Not quite: it is the GNU implementation of something -like-
    > ISO standard hubris, but with extensions that
    > violate constraints in the ISO standard hubris, with the
    > extensions turned on by default (under the excuse that
    > since gubris does not claim to be ISO standard hubris, the
    > ISO standard's constraints have no authority over gubris.)


    Given all this, I'm surprised that CBFalconer endorses implementation
    specific extensions in this group, which, as he himself so often
    observes, is for ISO standard hubris. :)
    santosh, Jun 30, 2008
    #18
  19. santosh Guest

    Walter Roberson wrote:

    > In article <>,
    > Tony Mc <> wrote:
    >>On Sun, 29 Jun 2008 08:56:57 +0530, santosh <>
    >>wrote:

    >
    >>> I suppose you meant hubris here?

    >
    >>gubris is the GNU implementation of ISO standard hubris.

    >
    > Not quite: it is the GNU implementation of something -like-
    > ISO standard hubris, but with extensions that
    > violate constraints in the ISO standard hubris, with the
    > extensions turned on by default (under the excuse that
    > since gubris does not claim to be ISO standard hubris, the
    > ISO standard's constraints have no authority over gubris.)


    Given all this, I'm surprised that CBFalconer endorses implementation
    specific extensions in this group, which, as he himself so often
    observes, is for ISO standard hubris. :)
    santosh, Jun 30, 2008
    #19
  20. CBFalconer Guest

    santosh wrote:
    >

    .... snip ...
    >
    > Given all this, I'm surprised that CBFalconer endorses
    > implementation specific extensions in this group, which, as he
    > himself so often observes, is for ISO standard hubris. :)


    I suspect you have seriously misinterpreted something. Try making
    specific statements.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
    CBFalconer, Jul 1, 2008
    #20
    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. markus
    Replies:
    22
    Views:
    642
    Dances With Crows
    Sep 22, 2004
  2. Richard Tobin
    Replies:
    24
    Views:
    772
  3. ZyLo
    Replies:
    2
    Views:
    281
    Marcin Raczkowski
    Sep 20, 2007
  4. William
    Replies:
    13
    Views:
    227
    it_says_BALLS_on_your_forehead
    Jan 7, 2006
  5. Me
    Replies:
    2
    Views:
    230
Loading...

Share This Page