Re: Vte pty

[Chris Moller <cmoller at redhat dot com>]

Andrew Cagney mumbled something on 04/07/06 17:47:
> First,  Java(tm) does not directly make available OS specific
> mechanisms such as forkpty, it has no reason to as it is not trying to
> be system specific.  Instead it provides us with the tools we need to
> make our own bindings.
>
>
> In my note I suggested:
>> Consequently, as best I can tell, for both those scenarios, just the
>> pty-slave is needed?  The pty-slave might either be the FD (an
>> integer) or more likely just the String that is the path to the
>> pty-slave device.
>>
>> Assuming it is, I'd not expect either of those scenarios to be
>> interested in the grotty non-portable system dependent details of
>> creating the pty master|slave pair.  Instead either:
>> - have the vte Java bindings worry about this returning just the
>> pty-slave's path
>> - have a separate binding for creating the pty master|slave pair and
>> pass that to the vte bindings?
>> Do either of these cases map onto what your describing below?  Do you
>> think the former has the simplest interface?
> Focusing on the first suggestion that the bindings worry about
> returning just the pty slave could something like:
>
>    gobject terminal = vte_terminal_new ()
>    openpty (&master, &slave, ...)
>    vte_terminal_set_pty (terminal, master)
>    return object containing terminal and path for slave device

I think maybe we're converging.  ;-)

Since the third arg to  openpty(int  *amaster,  int  *aslave,  char
*name, ...), if non-null, returns the slave path, all the data you need
seems to be there.  In the pure case, libvte-java would just provide
wrappers for vte_terminal_new (), returning a Java Handle, and
vte_terminal_set_pty () (which I still have to patch in), but doesn't
provide a clean way to include the openpty().  So how about this:  We've
already got a libftk.so that holds the custom widgets--how about I just
stick your snippet above into a little interface fcn (including the
third openpty() arg) and stuff that into libftk?  With the addition of a
Java wrapper for /that/, I think things will work.

>
> with code later either:
>
> - Open input and output streams on the slave pty (my first scenario)
> - fork, re-open to the slave, exec (my second scenario)

Is this going to be done in frysk-core?  Or as external fcns?  If the
latter, it can be bundled with the openpty() stuff.

Chris

>
> be made to work.
>
> The alternative is to, I guess add an extra CNI/JNI binding that
> creates a pty object and passes that, or its int value, to the vte
> binding.
>
> Andrew
>

Attachment: signature.asc
Description: OpenPGP digital signature