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

This is a discussion on forked child print in parent's shell using ncurses. how to? within the C Programming forums, part of the General Programming Boards category; how to make child to print where the parent is printing using ncurses.. my sample code is Code: #include <stdio.h> ...

  1. #1
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104

    Question [urgent!]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?
    Last edited by gibsosmat; 11-07-2007 at 02:40 AM.

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,750
    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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    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?

  4. #4
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,750
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  5. #5
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    Quote Originally Posted by Salem View Post
    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?

    Quote Originally Posted by Salem View Post
    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

  6. #6
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    no replies?
    C's Motto: who cares what it means? I just compile it!!

  7. #7
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    pipes.

  8. #8
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    Quote Originally Posted by zacs7 View Post
    pipes.
    and also thread to update the screen?
    C's Motto: who cares what it means? I just compile it!!

  9. #9
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Not necessarily, you could use select() or something similar.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    Quote Originally Posted by zacs7 View Post
    Not necessarily, you could use select() or something similar.
    ok.. I will learn about select()

    Quote Originally Posted by matsp View Post
    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
    C's Motto: who cares what it means? I just compile it!!

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by gibsosmat View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  13. #13
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    Quote Originally Posted by matsp View Post
    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)
    C's Motto: who cares what it means? I just compile it!!

  14. #14
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  15. #15
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    Quote Originally Posted by matsp View Post
    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
    C's Motto: who cares what it means? I just compile it!!

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. merging linked lists
    By scwizzo in forum C++ Programming
    Replies: 15
    Last Post: 09-14-2008, 06:07 PM
  2. Personal Program that is making me go wtf?
    By Submeg in forum C Programming
    Replies: 20
    Last Post: 06-27-2006, 01:13 AM
  3. pipe
    By smart girl in forum C Programming
    Replies: 4
    Last Post: 04-30-2006, 10:17 AM
  4. Scope And Parameter Passing
    By djwicks in forum C Programming
    Replies: 6
    Last Post: 03-28-2005, 08:26 PM
  5. What kind of programs should I start writing?
    By Macabre in forum C++ Programming
    Replies: 23
    Last Post: 04-12-2003, 09:13 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21