Re: Question about how to use newterm() to separate output streams

[Thomas Dickey]

On Wed, 14 Mar 2007, Christer Enfors wrote:

> I'm working on a program (in C, on AIX) called "instring". What I'm trying to 
> make it do is display a one-line form (I'm using filter()) containing a 
> single input field. After the user enters data in the input field, my program 
> should print that string, and quit. The reason why it should print that 
> string is because we have piles and piles of legacy scripts that captures 
> that output from the old version of instring (which I didn't write, and which 
> I'm now writing a replacement for). The scripts use this syntax to capture 
> the output from instring:
>
>  $ output=`instring`
>
> This is supposed to ONLY capture my final printing of the input field, after 
> the user is done typing it - but in my version of instring, it also captures 
> the input field itself (a row of A_UNDERLINE characters), etc.
>
> If I understood him correctly, Thomas Dickey kindly adviced me to use 
> newterm() to get around this problem, but I'm not sure how I should go about 
> it. Am I supposed to use newterm() to create a new SCREEN on which I should 
> display my form? And then print the input received on stdout, so that the 
> input is the only thing printed on stdout, and thus the only thing captured 
> by the calling script?
>
> But if the new SCREEN created by newterm() isn't connected to stdout, then 
> how do I make it even display? Should I use dup() (or something) to connect 
> the screen directly to the tty?

well - pointing in the right direction: newterm() has parameters to
associate the standard input/output of a terminal.  You shouldn't have
to use dup() to create new I/O streams if you already have workable ones
from the shell.

In dialog, I use newterm() to make it open /dev/tty even if stdin is 
already redirected, e.g., from a pipe (lynx does this as well). So (using 
that sort of approach), you could make your application read data from a 
pipe (stdin), open /dev/tty for input and run curses to talk directly to 
the user and write the results to some output (e.g., your own stdout if 
you also opened /dev/tty for output).

> Or am I totally off base here? I wouldn't be surprised, as this is all very 
> confusing for my little Swedish brain.
>
> --
> Christer Enfors
>
>
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-ncurses

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net