forked child print in parent's shell using ncurses. how to?

how to make child to print where the parent is printing using ncurses..
my sample code is

Code:

 
#include <stdio.h>
#include <sys/types.h>    
#include <ncurses.h>
 
 int main()
{
    pid_t childPid = 0;
 
   WINDOW *mywindow;
    mywindow = initscr();
    keypad(stdscr,TRUE);

    childPid = fork();
    if(childPid ==0)
    {
        wprintw(mywindow,"Inside Child\n");
        refresh();
        return 0;
    }
    else
    {
        wprintw(mywindow,"Inside Parent\n");
        refresh();
    }
 
    wscanf(mywindow,"%c");
    endwin();

    wait();

    return 0;
}

but the child part is not getting printed on the screen..
can anyone help me on this?

Or they both write to the same part of the screen, and the parent overwrites the child.

Perhaps some kind of "gotoxy" to give each process it's own area of the screen perhaps?

Though being separate processes, neither will know what the other is doing, so any refresh is just as likely to wipe out the entire output of the other process.

Where are you going with this idea?

> wscanf(main,"%c");
Aside from the dangers of having the variable name the same as a function, where exactly is the result of this "scanf" being stored?

no..
even if I change that variable name from 'main' to 'somethingelse' the result is the same..
As you said refresh() is likely to wipe out the screen.. why would the screen wipe out the changes made if there is nothing else written into the scr buffer at the same location?

> why would the screen wipe out the changes made if there is nothing else written
> into the scr buffer at the same location?
Because it's the first refresh call you've made?
True, after that, it should only update the parts of the screen which need to be updated. But AFAIK, if the change is sufficiently complicated, it might try to refresh the whole screen anyway.

> even if I change that variable name from 'main' to 'somethingelse' the result is the same..
It wasn't functional danger, it was a matter of style.

Originally Posted by Salem

Because it's the first refresh call you've made?
True, after that, it should only update the parts of the screen which need to be updated. But AFAIK, if the change is sufficiently complicated, it might try to refresh the whole screen anyway.

well, then how can I implement something like what i wanted?

• parent prints at one point, say top of the window
• child prints at the bottom of the window
• Both Parent & child print will only one line and not more than that.
  (so there is no prob of scrolling and overlapping)

and I dont want to get it complex making pipes & threads to update the screen from parent.
my code was only printing the parent process's commands, and not child..
any suggestions?

Originally Posted by Salem

It wasn't functional danger, it was a matter of style.

well.. that wasnt my code.. actual code was around 200 lines so I trimmed to what exactly I wanted and didnt pay much interest in coding style

no replies?

pipes.

Originally Posted by zacs7

pipes.

and also thread to update the screen?

Not necessarily, you could use select() or something similar.

This is a typical case of shared resources: You need one controlling point. So whether you like it or not, you can't do this reliably without using "pipes" and do the stuff in the main process. [Or something along those lines at least].

--
Mats

Originally Posted by zacs7

Not necessarily, you could use select() or something similar.

ok.. I will learn about select()

Originally Posted by matsp

This is a typical case of shared resources: You need one controlling point. So whether you like it or not, you can't do this reliably without using "pipes" and do the stuff in the main process. [Or something along those lines at least].

--
Mats

hmm.. but isnt stdscr somethiing like stdin? earlier I didnt use any sema and stuff for handling resource i.e stdin

Originally Posted by gibsosmat

hmm.. but isnt stdscr somethiing like stdin? earlier I didnt use any sema and stuff for handling resource i.e stdin

Ok, first of all, if we have two threads/processes reading the stdin, one will get into the OS call for "read" first, and as long as the read is satisfying the entire data input, that will be atomic - if there is a need for multiple reads, then there may be a problem. If you are in "cooked mode" [that is, the OS IO subsystem takes care of editing with backspace and complete the input with enter] it will be one complete IO request to read the data. If you use "raw mode", then I expect your input would be "all over the place".

Output likewise. If you use "setvbuf()" to make the stdout unbuffered, I expect your data to be completely scrambled. If you use the standard settings, output will be linewise complete.

--
Mats

Originally Posted by matsp

Ok, first of all, if we have two threads/processes reading the stdin, one will get into the OS call for "read" first, and as long as the read is satisfying the entire data input, that will be atomic - if there is a need for multiple reads, then there may be a problem. If you are in "cooked mode" [that is, the OS IO subsystem takes care of editing with backspace and complete the input with enter] it will be one complete IO request to read the data. If you use "raw mode", then I expect your input would be "all over the place".

Output likewise. If you use "setvbuf()" to make the stdout unbuffered, I expect your data to be completely scrambled. If you use the standard settings, output will be linewise complete.

--
Mats

ok.. I am using pipe() call.. I think its raw mode..
so do I have to sync it depending on what I want to do with the stream?
(all I want to do: scan a line and print it)

Ehm, I was referrint to you "earlier I was using stdin without synchronization", and I still believ the reason this worked is that the IO subsystem is part of the processing, and it synchronizes for you. And if your "pipe" comment is related to the stdin/stdout reading in multiple processes [e.g. forked processes] where both processes use stdin/stdout simultaneously, the pipe is not related to raw or cooked mode. You'd need to use a special call to ioctl to change the input mode of the code, and this is unrelated to the use of pipe or not.

As to how you do things now:
If you have one main application that reads data from one or more subprocesses, it will work just fine with ncurses to do that - because you now have only ONE ncurses process. The fact that the data you are using WITHIN ncurses comes from multiple processes is irrelevant. You will have one pipe per subprocess, so it should be easy to separate what comes from what process.

Or did I not understand what you wanted to know correctly?

--
Mats

Originally Posted by matsp

Ehm, I was referrint to you "earlier I was using stdin without synchronization", and I still believ the reason this worked is that the IO subsystem is part of the processing, and it synchronizes for you. And if your "pipe" comment is related to the stdin/stdout reading in multiple processes [e.g. forked processes] where both processes use stdin/stdout simultaneously, the pipe is not related to raw or cooked mode. You'd need to use a special call to ioctl to change the input mode of the code, and this is unrelated to the use of pipe or not.

As to how you do things now:
If you have one main application that reads data from one or more subprocesses, it will work just fine with ncurses to do that - because you now have only ONE ncurses process. The fact that the data you are using WITHIN ncurses comes from multiple processes is irrelevant. You will have one pipe per subprocess, so it should be easy to separate what comes from what process.

Or did I not understand what you wanted to know correctly?

--
Mats

naa, you got it right..
I was trying to get my thing done without getting my hands dirty.. lol..
if I really had to do all that.. there is noway.. like in any GUI based programming.. gui is always controlled by one process.. and the data is modified by the rest..
I was thinking if the ncurses screen works like stdout.. that I go and put printw() where ever I want and it will work just fine..
but sad .. I think I have to do all that bookkeeping of how many children, and their fds and pipes..
but I dont find any other alternatives..

btw can it be done.. like, I use the same pipe for writing from many child process to the parent.. and from there I can read what I am getting and parse it..
I am on linux + GCC-4.1X