This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Vte pty


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]