Run native executable in a plugin, Apache commons exec or processbuilder???

[Daniel White]

hi folks,
Did anyone ever make a plugin or script or macro that runs a native
executable as a sub process  , perhaps using Apache commons exec or the
native Java processbuilder?

Processbuilder looks quite easy, but Apache commons exec has nice stuff
like asynchronous execution....

Any code/tips/advice?

For example, if I want to write a ImageJ plugin with a gui for setting
command line parameters for a user defined linux c++ executable, and have
the plugin run the executable on a image file and deal with the standard
error and output, by eg . dumping them in a text file.

Just to make it easy to run a linux executable on an image.... From
inside imageJ....
An open image knows where it's file was opened from right? So the plugin
could use that file name as a parameter for the Linux executable, catch the
exit signal from the executable, then open the result image.

Did anyone solve that already?


Best

Dan

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Dan,

On Wed, 15 Oct 2014, Daniel White wrote:

> Did anyone ever make a plugin or script or macro that runs a native
> executable as a sub process  , perhaps using Apache commons exec or the
> native Java processbuilder?

Yep, sure I do. The org.scijava.util.ProcessUtils is designed to help you
with that:

        http://jenkins.imagej.net/job/SciJava-common-javadoc/javadoc/org/scijava/util/ProcessUtils.html

It is basically a clean rewrite of the now obsolete fiji.SimpleExecuter
class:

        http://jenkins.imagej.net/job/Fiji-javadoc/javadoc/fiji/SimpleExecuter.html

Both classes are available as part of Fiji. The main difference is that
the SimpleExecuter logs the output of the command to the Log window, while
the ProcessUtils return the output as a String. Here is a simple BeanShell
script demonstrating both (the /bin/echo command is available on Linux and
on MacOSX, on Windows you need to use something else):

        fiji.SimpleExecuter.exec(new String[] {
                "/bin/echo", "Hello, Dan!"
        });
        out = org.scijava.util.ProcessUtils.exec(null, null, null,
                new String[] { "/bin/echo", "Hello, Dan!" }));
        ij.IJ.log(out);

Ciao,
Dscho

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Daniel White]

Hi Dschowe,


On Wednesday, October 15, 2014, Johannes Schindelin <
[hidden email]> wrote:

> Hi Dan,
>
> On Wed, 15 Oct 2014, Daniel White wrote:
>
> > Did anyone ever make a plugin or script or macro that runs a native
> > executable as a sub process  , perhaps using Apache commons exec or the
> > native Java processbuilder?
>
> Yep, sure I do. The org.scijava.util.ProcessUtils is designed to help you
> with that:
>
>
> http://jenkins.imagej.net/job/SciJava-common-javadoc/javadoc/org/scijava/util/ProcessUtils.html
>
> It is basically a clean rewrite of the now obsolete fiji.SimpleExecuter
> class:
>
>
> http://jenkins.imagej.net/job/Fiji-javadoc/javadoc/fiji/SimpleExecuter.html

Ah! Jolly good!

>
> Both classes are available as part of Fiji. The main difference is that
> the SimpleExecuter logs the output of the command to the Log window, while
> the ProcessUtils return the output as a String. Here is a simple BeanShell
> script demonstrating both (the /bin/echo command is available on Linux and
> on MacOSX, on Windows you need to use something else):
>
>         fiji.SimpleExecuter.exec(new String[] {
>                 "/bin/echo", "Hello, Dan!"
>         });
>         out = org.scijava.util.ProcessUtils.exec(null, null, null,
>                 new String[] { "/bin/echo", "Hello, Dan!" }));
>         ij.IJ.log(out);
>
>
> Great!

So if the eg. Linux executable might take a long time to run, Should I
also make sure it can be killed if it hangs or times out , and somehow
catch its successful completion signal... To know when I can then get
imageJ to load the result image file, if I want the plugin to also do that.

Should I also make sure the executable runs in a different thread to the
GUI? So it doesn't block important stuff?

what to watch out for to make sure the plugin could also be run in a
headless situation ? Separate the GUI from the part that does the execution
I guess...

And to make sure the plugin can be run in batch mode via the multi image
processor, or what ever it's called these days....

Dos and don'ts to make sure it's as general as possible?

D

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Dan,

On Wed, 15 Oct 2014, Daniel White wrote:

> Hi Dschowe,

Almost.

> On Wednesday, October 15, 2014, Johannes Schindelin <
> [hidden email]> wrote:
>
> > On Wed, 15 Oct 2014, Daniel White wrote:
> >
> > > Did anyone ever make a plugin or script or macro that runs a native
> > > executable as a sub process  , perhaps using Apache commons exec or the
> > > native Java processbuilder?
> >
> > Yep, sure I do. The org.scijava.util.ProcessUtils is designed to help you
> > with that:
> >
> >
> > http://jenkins.imagej.net/job/SciJava-common-javadoc/javadoc/org/scijava/util/ProcessUtils.html
> >
> > [...]
>
>
> So if the eg. Linux executable might take a long time to run, Should I
> also make sure it can be killed if it hangs or times out , and somehow
> catch its successful completion signal... To know when I can then get
> imageJ to load the result image file, if I want the plugin to also do
> that.

The utilities I presented do not have (yet) options for a timeout. For the
moment, you need to use Java6' ProcessBuilder (or System.exec()) for that,
and kill the Process if it runs too long a time.

Or you contribute the feature by modifying SciJava commons' ProcessUtils.

> Should I also make sure the executable runs in a different thread to the
> GUI? So it doesn't block important stuff?

Yes, you need to run this on a different thread. Killing the thread will
not kill the process, BTW.

> what to watch out for to make sure the plugin could also be run in a
> headless situation ? Separate the GUI from the part that does the
> execution I guess...

That is one thing to watch out for, yes.

> And to make sure the plugin can be run in batch mode via the multi image
> processor, or what ever it's called these days....
>
> Dos and don'ts to make sure it's as general as possible?

Ideally, if you require a bit more than the current library versions
provide (such as the timeout feature), it is preferable to enhance the
library. That way, many plugins can benefit from a generic, reusable
solution.

If you have some public source code repository with the work in progress,
feel free to point me to it so I can have a look.

Ciao,
Dscho

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html