Topic awaiting preservation: C++ help (Page 1 of 1)

where would I post questions regarding some C++ code?

Thanks,
**Mister God

first and foremost, welcome to the asylum. A nurse will be by shortly to administer your pills and make sure your straight jacket is nice and snug.

as far as C++ questions, not too sure where you'd post them, but this thread will work for the moment I'm sure, and if there happens to be a particular forum for it a mad scientist will likely move it there.

so shoot




...Of all the things I've lost, I miss my mind the most (ozzy osbourne)

I would guess the forum "Server-Side Scripting - Oh my! " would be the most apropriate, because it's the closest one I can see to c++ programming, and I believe cgi can be c++ programs.

yeah, that would do it. And I'll move it there now. You'll be able to use the moved notice to go there.

Welcome Mister,

There are competent fellows over here.

Shoot your question.

--
Regards,
Elias

Thanks for the welcome.

I'm in a rush right now, so I have to be brief. I am *trying* to write the unix & operator in C/C++. The operator makes the typed command run in the background, and I'm not sure where to get started.

I was thinking of moving that process (the one generated by entering the command with & ) into another process group and then returning control back to the shell process. I think I could do this by using semaphores(to return control to the shell) and shared memory(to hold the group pid of my background processes).

This seems like it might be needlessly complex, does anyone know of a better/easier solution, or if this solution will even work?

Thanks everyone

(Edited by Mister God on 11-12-2004 18:00)

After thinking about it a bit more, I think I can just fork() off a child process (the command to be sent to the background) and not wait for it to finish. I was thinking of maintaining a stack/array of processes sent to the background so that I can bring the most recent process sent to the background to the foreground via fg.

Any obvious flaws in my reasoning?

Thanks again

Your idea to fork a child is going in the correct direction. After the fork, use one of the exec commands to execute the processes you want to run in the background. After the fork, both the parent and the child will continue to run more or less independently. On successful creation of the child, 'fork' will return the child's pid to the parent process and will return 0 to the child process. If not successful, the return value (to the parent only) is -1 and errno is set.

Yes you can maintain a list of pids of the children so the parent can maintain a status of the child. In order for the parent to communicate with the child, you will need to use semaphores, pipes, or shared memory. (I have listed those in the order I perfer to use them.)

It is possible to disassociate the child from the parent. I don't remember how just now. What I am remembering is that the child will die if the parent dies.

Why are you trying to recreate the unix command shell? Are you just using '&' and 'fg' as a means to discuss this problem or are you really trying to program a new shell?

-- not necessarily stoned... just beautiful.

I am writing a basic shell for a class, but the professor and TA are intentionally vague so I am looking for other places to garner the needed knowledge to write the shell.

Thanks for the reply, its nice to have confirmation that I'm heading down a viable path.