Newbie Question about multiple system calls within loops

S

student.matt

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
 
R

rahul

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.
 
J

Johannes Bauer

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
 
S

Stephen Sprunk

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
 
V

vippstar

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.
 
S

student.matt

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


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



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
 
A

Antoninus Twink

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;
}
 
C

Chad

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.
 
C

Chad

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.
 
K

Keith Thompson

Chad said:
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.

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.
 
M

Martien Verbruggen

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
 
A

Antoninus Twink

\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.
 
S

Stephen Sprunk

Antoninus said:
?? 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.
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
 
S

Stephen Sprunk

Antoninus said:
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
 
C

CBFalconer

Chad said:
.... snip ...

.... 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.
 
W

Walter Roberson

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.)
 
S

santosh

Walter said:
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. :)
 
S

santosh

Walter said:
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. :)
 
C

CBFalconer

santosh said:
.... 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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top