JACL - redirection of std* channels
Sektor van Skijlen
I have an application that uses Tcl-based (standalone) application by just
executing the tclsh with channel two-way redirection.
As now this application is in Java, I would like to use Jacl to perform the
job of interpreting the Tcl scripts.
My first idea was to replace the "Runtime.getRuntime().exec(...)" with Jacl's
Interp.evalFile(). However, how would I redirect channels?
The Tcl script is desitned as a console application that communicates with
stdin/stdout. I need that it be possible to run this, even in a separate
thread, but in such a form that the data written to stdout in this Tcl
application are being able to be read by the Java application that spawns it.
Is it possible?
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethouris(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"
Tom Poindexter
Sektor van Skijlen <etho...@guess.if.gmail.com.is.valid.or.invalid> wrote:
>`lo,
>
>I have an application that uses Tcl-based (standalone) application by just
>executing the tclsh with channel two-way redirection.
>
>As now this application is in Java, I would like to use Jacl to perform the
>job of interpreting the Tcl scripts.
>
>My first idea was to replace the "Runtime.getRuntime().exec(...)" with Jacl's
>Interp.evalFile(). However, how would I redirect channels?
>
>The Tcl script is desitned as a console application that communicates with
>stdin/stdout. I need that it be possible to run this, even in a separate
>thread, but in such a form that the data written to stdout in this Tcl
>application are being able to be read by the Java application that spawns it.
>
>Is it possible?
Assuming you are initializing your Jacl Interp from your
own Java code, you should be able to change stdin/stdout/stderr
by invoking the following with your own InputStream and
OutputStream:
StdChannel.setIn(InputStream in)
StdChannel.setOut(PrintStream out)
StdChannel.setErr(PrintStream err)
--
Tom Poindexter
tpoi...@nyx.net
ethouris
> Assuming you are initializing your Jacl Interp from your
> own Java code, you should be able to change stdin/stdout/stderr
> by invoking the following with your own InputStream and
> OutputStream:
>
> StdChannel.setIn(InputStream in)
> StdChannel.setOut(PrintStream out)
> StdChannel.setErr(PrintStream err)
Wow! Wonderful, but... could you tell me, what version it is and where
I can download it?
I tried Jacl version 1.4.1 found on Sourceforge, but the StdChannel
class does not have any of these methods!
Tom Poindexter
This is on the CVS HEAD:
see lines 60-70. These are static methods for the class.
ChangeLog entry at:
http://tcljava.cvs.sourceforge.net/tcljava/tcljava/ChangeLog?revision=1.491&view=markup
--
Tom Poindexter
tpoi...@nyx.net
Sektor van Skijlen
> In article <6b0d84fe-1212-43a5...@s12g2000prg.googlegroups.com>,
> ethouris <etho...@gmail.com> wrote:
> >On 25 Lut, 23:50, tpoin...@nyx.net (Tom Poindexter) wrote:
> >> Assuming you are initializing your Jacl Interp from your
> >> own Java code, you should be able to change stdin/stdout/stderr
> >> by invoking the following with your own InputStream and
> >> OutputStream:
> >>
> >> ? ? StdChannel.setOut(PrintStream out)
> >> ? ? StdChannel.setErr(PrintStream err)
> >
> >Wow! Wonderful, but... could you tell me, what version it is and where
> >I can download it?
> >
> >I tried Jacl version 1.4.1 found on Sourceforge, but the StdChannel
> >class does not have any of these methods!
> This is on the CVS HEAD:
> see lines 60-70. These are static methods for the class.
> ChangeLog entry at:
> http://tcljava.cvs.sourceforge.net/tcljava/tcljava/ChangeLog?revision=1.491&view=markup
And plans for the release?
I am using currently tclsh8.5 for Cygwin (manually compiled) because the
Windows version reveals some bug when Tcl is spawning an application through
[open] - deadlock on [gets] (only in combination: Java + Tclsh for
Windows - no reproduction on Linux, Cygwin and C++ version of the master
application). Using Jacl would really simplify the deployment (stating that
the Tcl-Windows version can't be used), but I would really know the release
plans for this version of Jacl before I plan anything in my project.
Tom Poindexter
Sektor van Skijlen <etho...@guess.if.gmail.com.is.valid.or.invalid> wrote:
>
>
That I don't know. Probably better to ask on the tcljava-dev mailing list,
see:
http://sourceforge.net/mail/?group_id=13005
for mailing list info.
--
Tom Poindexter
tpoi...@nyx.net