On 08/26/11 23:55, Matthias Melcher wrote:
> Well, for now the popen solution is somewhat OK.
> I want Fluid to launch all kinds of tools, which usually
> only requires reading characters from the tools.

> It would be nice to have some way to send characters as well,
> for example for launching gdb

        I had some time this weekend to make a variation that works
        with interactive programs like gdb(1). It's unix only,
        but handles stdin, stdout, and stderr asynchronously:

        http://seriss.com/people/erco/fltk/unix-bidir-dumb-terminal.cxx

        It uses pthreads and bidirectional pipe(2)s. All FLTK operation
        is handled by the parent; the threads are just data pumps.
        [I chose not to use add_fd() to facilitate a Windows port]

        With some work, it could be extended to support windows;
        the mechanics should be able to be ported to use the WIN32
        CreatePipe()/CreateThread()/CreateProcess() and friends.

        Basically the "MyTerminal" class from my original example
        has been extended to handle bi-directional interaction
        with the child process.

        You'll see actual prompts from the shell and interactive tools,
        and can interact with them asynchronously.

        The example opens up a tcsh prompt. So you can fire off
        interactive programs like gdb(1) and nslookup(1), and you
        can interact with them normally. (see caveats below)

        Tested on linux and osx.

CAVEATS
        Some simple line editing is supported: backspace, ^U, ^W, Enter.
        That's it. Other special characters may yield 'undefined behavior'.

        Does NOT support pty features like job control, EOF, 'raw' modes.
        So for instance, ^Z, ^C, or ^D are not supported.
        Also: no inline editing like ^A, ^E, ^P, ^N, arrow keys, etc.

        Because this is implemented around Fl_Text_Editor, many of
        the editor's features are available that shouldn't be;
        the arrow keys and mouse clicks can move the text cursor up into
        the screen history.

        Some additions are necessary to handle reaping the child process,
        and to allow the ability to kill the child and start a new one.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to