How long does your sub-program take to run?
What I'm wondering is if it has to be "owned" by something, either your main program or a terminal window...
My thought being that you called this sub-program and it's parent (your program) exited before it ran but with
a terminal window loaded calling system() meant it could run because the terminal owned it and stayed open long enough.
The sub program (the file that was created by my program, called 'getkod', takes just over one second to contact the server, sign in, and download the file.
From my understanding of the system() call, it waits until the child process either fails or is complete before returning to the next program line in the main program. So, again, from my understanding, the external file is asked to execute from the main program and then waits for a return code, indicating success or failure. In order to return one of those codes, I would think that the system shell would have to have run the program and either there was something wrong in the program that caused it to fail or it succeeded. Since there is nothing wrong with the commands in the sub program, it should run properly.
One of two scenarios happen.
1. If the main program is started by clicking on an icon, where no terminal is used, the external file is actually being run, but for some reason, without that 'sleep' statement at the end, returns without successfully running properly. Properly is the key word here. Why if I delay the return, does the program actually run properly? If I use a debugger and step through it, it executes one statement at a time, properly. Shouldn't this happen regardless of where the program was started from? This is the same behavior, using my very small program that ONLY tries to execute that sub program (the getkod file).
2. If the main program is started by use of a terminal, the external file DOES run to completion properly, before returning to the main program.
By my creating the very basic simplified program that only tries to execute that external file (getkod), there is nothing else to do in the main program after that system call. Therefore, the program ends. That should not affect the child process from executing properly.
For some reason, the shell is telling the return call to return, without having actually run the program. On the server, there is no attempt to login when this happens.
Your theory might hold water except for the fact that the main program continues and does other things, after the system call, before it dies. This 'should' give the sub program plenty of time to complete.
The strange part is that the child process does actually run, or at least ps shows it running. Even if I put a sleep statement just after the remote system is asking for a password, it never actually goes out to the remote server asking to login. It's as if that child process doesn't run until it completely executes and then need a small amount of time to perform it's actions.
You have to admit that this is very strange behavior.
Again, thanks for your help. I'm going to change my program to use that work-around for now. I may never fully understand what is happening here, which bother's me.
