Re: Vte pty

[Chris Moller <cmoller at redhat dot com>]

The vte pty function is

    vte_terminal_set_pty(VTE_TERMINAL (terminal), pty_master);

where "terminal" identifies a newly-created (with vte_terminal_new ())
vte and pty_master is an fd.  The working example I have for this
(inspired by some comments by Roland) is:

    int pty_master;
       gboolean rc;

       pid_t pid = forkpty (&pty_master, NULL, NULL, NULL);
       if (pid == 0)
         {
           execl ("/bin/sh", "sh", NULL);
           _exit (127);
         }
       else if (pid < 0)
         perror ("forkpty");
       else {               /* parent */
         rc = vte_terminal_set_pty(VTE_TERMINAL (terminal), pty_master);
         fprintf (stderr, "rc = %s\n", (TRUE == rc) ? "TRUE" : "FALSE");
       }

where the forkpty not only does the fork but provides the pty fds as
well (the second parm to forkpty() can be an int pointer where the slave
fd is stored, but I don't know if the parent side sees that).

After looking through the Java docs for a while, I could find nothing
that suggested Java knew anything about something so close to the
underlying OS as a file descriptor, so what I had in mind was
incorporating the forkpty() into the C portion of the Java wrapper and
returning the pid and fds to frysk.  But, as I said, I could be /way/
wrong about Java's capabilities, and/or about what happens deep inside
frysk. 

All I really need from frysk to make this play is that pty_master fd--if
there's a way that can be handed to me, all is happy, at least on my
end.  Can frysk's "internal fork/exec" be a forkpty/exec instead to
provide the fds? Or something equivalent?

(IIRC, there's a function that, given the pty path, will return the
corresponding fd.  If Java is happier just providing that path, I can
probably work with it, but I'd have to confirm my memory of things
before guaranteeing that.  I /think,/ similarly, there's a means of
translating a pty fd into its corresponding path string so if frysk uses
forkpty, it can get the pty paths.)

Re the VteStream thing, my thought was that since Java doesn't seem to
understand fds, I could provide the stream class to intermediate--if
Java /can/ use fds, or converting the fds into pty paths Java can use
actually works, there probably isn't any need for that class.

Chris

Andrew Cagney mumbled something on 04/07/2006 04:12 PM:
> Chris Moller wrote:
>> A couple of weeks ago when I posted the vte pty patch, I had naively
>> assumed that  opening  a pty to pass to vte would be trivial to those of
>> you who Java well.  But, having looked through the Java docs, it appears
>> that it's far beneath the dignity of the language to deal directly with
>> anything so plebeian as a pty.
>>
>>   
> I'm somewhat lost by this, but I'm guessing that you're talking about
> creating a pty master|slave pair from java and then passing that to
> this interface?
>
> Taking a step back, there are two intended uses for this code:
>
> - as a command line interface - the code would need to create input,
> output, and error streams connected to the pty-slave
> - as a sub-program console - as part of frysk's internal fork|exec,
> the sub-programs stdin, stdout, and stderr would be wired up to the
> pty-slave
>
> 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?
>
> Andrew
>
>
>> Plan B:  A couple of months ago, at Andrew's suggestion, I wrote a
>> VteStream class that extended the standard Java Input- and
>> OutputStreams.  That class was based on vanilla vte; my proposed Plan B
>> is to re-implement the class using  pty-patched vte and incorporating a
>> forkpty() as a native method (or whatever you call it...) to open the
>> pty.  (Oops, I need to pass an int pointer to do that... I don't think
>> Java can do that...  Oh, well, Plan B-prime...) The actual pty would be
>> opaque to Java--I'm not sure Java could even make proper use of it
>> anyway, but I could easily be wrong.
>>
>> Any objections?  Any shouts of "You've /got/ to be kidding!"?
>>
>> cm
>>
>>
>>
>>   
>

Attachment: signature.asc
Description: OpenPGP digital signature