Re: Vte pty

[Andrew Cagney <cagney at redhat dot com>]

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.

Chris Moller wrote:
> 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:
>
>   
I outlined_two_ scenarios:

> - 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

I don't see how this code:

>     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");
>        }
>
>   
addresses the first of those.

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

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)

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