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>
...

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.

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

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].

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

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.

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.

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