[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Dickey
Subject: Re: Question about how to use newterm() to separate output streams
Date: Wed, 14 Mar 2007 10:13:06 -0400 (EDT)

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

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]