Well thats the problem. I can do the exact same thing in the terminal or a bash script and achieve the same thing, try it with c++ using system() and let me know.
You can do
what exact same thing? Run telnet in background, and see it become a stopped process?
You started with this command, but I still don't understand what you're expecting to achieve with it:
Code:
telnet someserver someport &
To me, it seems like nonsense. It makes no more sense than this command:
Both commands have the same basic problem: they reach a point where they read from stdin, but there is no redirection of stdin, so they both end up being suspended processes (or they're terminated). Unless you take them out of background suspended state, they will wait forever, because there is no way to feed their stdin streams. And if they're terminated, then there's no suspended state to take them out of, so you're even farther away from doing anything useful.
Here's another useless command:
Code:
telnet someserver someport </dev/null
It makes about as much sense as the others, but the nonsensicality is more apparent because stdin is redirected to /dev/null.
This is what
telnet someserver someport & does
in isolation, from a Terminal shell, or from a shell script. I emphasize
in isolation, because that's the only thing you've posted: an isolated command line.
You haven't posted your shell script, which you say works. You haven't described what you're trying to accomplish in this shell script, nor in the call to system(), so there is no way for anyone else to understand the context of that isolated command.
To me, every one of these commands behaves exactly the way I'd expect: it terminates or suspends, after making the connection. What happens next is irrelevant. In both cases, the backgrounded telnet is a useless process, because no further commands can be issued without a stream or pipe to the telnet process's stdin.
When I run this C program:
Code:
#include <stdlib.h>
int main (int argc, const char * argv[])
{
system( "telnet solo.local 80 &" );
}
I see this output, where solo.local is the name of my server, and port 80 is where it's listening:
Code:
Trying 192.168.1.21...
Connected to solo.local.
Escape character is '^]'.
Connection closed by foreign host.
There is no telnet process remaining as a child of launchd. It terminated when it failed to obtain a readable stdin.
In particular, telnet made a connection (evidenced by "Connected to solo.local"). It then tried reading its stdin for commands, but since the shell that started it (the shell launched by system()) had terminated already, there was no controlling terminal on the telnet process. So with no controlling terminal (thanks to launchd), the SIGTTIN signal ends up terminating the process rather than suspending it. That termination is evidence by "Connection closed by foreign host".
The absence of a telnet process is evidenced by this command line, pasted into a Terminal window after the above program is run:
If there is any process that contains the word telnet anywhere in the process name or any command-line args, it will appear in the output. The only thing that ever appears is the grep command itself. Hence, there is no telnet process.
Once again, with no commands being fed to telnet, and no way to feed it anything because it's in background, the isolated command is nonsense. It makes the connection and then terminates. I see nothing useful that can be accomplished by putting telnet in background, using either system() in a C program, or using a shell script, or using a manual Terminal command-line.
This is why I'm asking for you to describe what you're trying to accomplish, or what you expect to happen. To me, it's nonsense, or at best an incomplete description.
The os will block the connection when its a background process executed from the c++ program (That's what i'm thinking, I could be wrong).
I don't understand what you mean by "block the connection".
The telnet command runs and makes the connection (see evidence above). After that point, telnet reads stdin for commands, but there's nothing there. That's the point I've been trying to make:
there's nothing to read from stdin, so at that point telnet fails. It already made the connection, but beyond that is where the whole thing becomes nonsense. If telnet has no input to read, it can't do anything else.
The only distinction is how the backgrounded telnet fails. When run at an interactive shell in Terminal, the backgrounded telnet is stopped (suspended) because there is a controlling terminal. When run via system(), there is no controlling terminal, so the backgrounded telnet is simply terminated.
I'm looking more towards daemons since the parent process happens to be launchd not sh. It's just one of those things that needs a way more in depth look at.
Launchd is just the parent process of last resort. It inherits the telnet child process when the shell that launched it dies. "Looking more towards daemons" makes no sense to me.
