By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
 449,109 Members | 1,008 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,109 IT Pros & Developers. It's quick & easy.

# Newbie Question about multiple system calls within loops

 P: n/a 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 #include 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 27 '08 #1
Share this Question
23 Replies

 P: n/a On Jun 26, 8:01 am, student.m...@gmail.com 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 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. Jun 27 '08 #2

 P: n/a st**********@gmail.com 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 <47***********************@news.freenet.de> Jun 27 '08 #3

 P: n/a st**********@gmail.com 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 #include 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 Jun 27 '08 #4

 P: n/a On Jun 26, 6:02 pm, Stephen Sprunk #include 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 27 '08 #5

 P: n/a On Jun 26, 5:34 pm, vipps...@gmail.com wrote: On Jun 26, 6:02 pm, Stephen Sprunk #include 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 27 '08 #6

 P: n/a On 26 Jun 2008 at 19:13, st**********@gmail.com wrote: student.m...@gmail.com 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 #include #include #include 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; } Jun 27 '08 #7

 P: n/a On Jun 26, 12:28*pm, Antoninus Twink #include #include #include 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 - Jun 27 '08 #8

 P: n/a On Jun 26, 12:28*pm, Antoninus Twink #include #include #include 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. Jun 27 '08 #9

 P: n/a Chad #include #include #include 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. No, it's correct; it's used to mark the end of the arguments. 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) ks***@mib.org Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" Jun 27 '08 #10

 P: n/a On Thu, 26 Jun 2008 17:20:50 -0700 (PDT), Chad On 26 Jun 2008 at 19:13, student.m...@gmail.com 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/...ions/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 Jun 27 '08 #11

 P: n/a Antoninus Twink wrote: On 26 Jun 2008 at 19:13, st**********@gmail.com wrote: >>>student.m...@gmail.com 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 thesystem("kedit &"); did work read the man on system() little bit betterunderstanding of whats going on. i looked up 10 differentdocumentations 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 #include #include #include 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; } 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. S Jun 29 '08 #12

 P: n/a Chad wrote: Antoninus Twink >It's really not all that complicated. Here's a simple examplethat 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]: Try the download section. Jun 29 '08 #13

 P: n/a CBFalconer wrote: Chad wrote: >Antoninus Twink > >>It's really not all that complicated. Here's a simple examplethat addresses your original question: ... snip twink gubris ... I suppose you meant hubris here? Jun 29 '08 #14

 P: n/a 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. Tony Jun 30 '08 #15

 P: n/a In article , Tony Mc 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) Jun 30 '08 #16

 P: n/a Walter Roberson wrote: In article , Tony Mc >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. :-) Jun 30 '08 #17

 P: n/a Walter Roberson wrote: In article , Tony Mc >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. :-) Jun 30 '08 #18

 P: n/a 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]: Try the download section. Jul 1 '08 #19

 P: n/a santosh wrote: CBFalconer I noticed that you also brought up Jacob's name in another thread today, in a similarly stupid way. -- pete Jul 1 '08 #20

 P: n/a CBFalconer wrote: santosh wrote: >> ... snip ... >>Given all this, I'm surprised that CBFalconer endorsesimplementation specific extensions in this group, which, as hehimself so often observes, is for ISO standard hubris. :-) I suspect you have seriously misinterpreted something. Try making specific statements. It was in jest. That's why I put the smiley there. In any case, apologies if I have offended you. Jul 1 '08 #21

 P: n/a pete wrote: santosh wrote: > CBFalconer I noticed that you also brought up Jacob's name in another thread today, in a similarly stupid way. Both were attempts at humour, but I guess it failed. Jul 1 '08 #22

 P: n/a santosh wrote: pete wrote: >santosh wrote: >> CBFalconer I noticed that you also brought up Jacob's namein another thread today, in a similarly stupid way. Both were attempts at humour, but I guess it failed. I don't recall seeing Jacobs response, if any. However I suspect mine was considerably calmer. :-) -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: Try the download section. Jul 1 '08 #23

 P: n/a CBFalconer wrote: santosh wrote: >pete wrote: >>santosh wrote: CBFalconerI noticed that you also brought up Jacob's namein another thread today, in a similarly stupid way. Both were attempts at humour, but I guess it failed. I don't recall seeing Jacobs response, if any. However I suspect mine was considerably calmer. :-) s/considerably/a shade/ 8-) Bye, Jojo Jul 1 '08 #24

### This discussion thread is closed

Replies have been disabled for this discussion.