Redirecting stdin (was Re: retokenize tables)
Jay R. Ashworth
jra at baylink.com
Wed Jan 24 10:17:39 PST 2007
On Wed, Jan 24, 2007 at 12:28:57PM -0500, Kenneth Brody wrote:
> Quoting Jay R. Ashworth (Wed, 24 Jan 2007 00:47:40 -0500):
> [...]
> > you pipe the appropriate keystrokes into dcabe which (mirabile visu)
> > *actually read STDIN*.
> [...]
>
> The Unix versions of filePro have always been able to redirect stdin
> (as well as stdout and stderr), because that's the way Unix works.
That's the way it works if you're not a full-screen application.
*Most* Unix fullscreen apps use curses, which breaks that. Using
termcap itself can break it, if you're not careful about how you write
the code.
> You could even fake special keystrokes by forcing TERM to a fixed
> value and putting the appropriate escape sequences in the stream to
> be read by filePro.
That was how I did it, yeah. :-)
> Windows, on the other hand, simply doesn't work that way. The console
> API functions just don't work as expected if you are not really using
> the console as I/O.
Nope, it don't. :-)
> Normally, filePro uses "CONIN$" and "CONOUT$" for input/output, which
> are not affected if stdio is redirected. You can tell filePro to use
> STD_INPUT_HANDLE and STD_OUTPUT_HANDLE (the Windows names for stdin
> and stdout) by setting PFNEWNTCONSOLE=OFF. filePro will continue to
> work with this if you don't redirect stdio. However, if you run like
> this outside of a GI environment, and redirect stdio, filePro will
> hang due to the console API calls failing. (Specifically, the
> PeekConsoleInput API call fails with an "invalid handle" error, as
> the handle is not a console handle. I'm pretty sure that the
> ReadConsoleInput API call would fail the same way for the same
> reason.)
Yay, Microsoft!
Cheers,
-- jra
--
Jay R. Ashworth jra at baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
More information about the Filepro-list
mailing list