Display STDOUT of commands in window

Hi,

I have a set of perl scripts which are usually called from the command
line. I would like to make a simple GUI, which has buttons to start each
of them, and a box where the STDOUT of each script is diplayed live. I
came across this:

button($but_frame, "Run",  "Run", sub { $output->insert('end', qx(
script.pl ))});

where $output is a read only listbox.

which works, but the frame is updated only when the script.pl is
finished, and the GUI is inactive during this. I have also tried using:

tie(*STDOUT, 'Tk::Text', $output);

This seems to work for the STDOUT of the GUI, but the STDOUT of the
executed scripts lands in the xterm where the GUI was started.

Any ideas are much appreciated.

David.

"David Herbison" <dh123.ml@gmx.net> schrieb im Newsbeitrag
news:co0617$85o$1@online.de...
> of them, and a box where the STDOUT of each script is diplayed live. I
> came across this:
>
> button($but_frame, "Run",  "Run", sub { $output->insert('end', qx(
> script.pl ))});
>
> where $output is a read only listbox.
>
> which works, but the frame is updated only when the script.pl is
> finished, and the GUI is inactive during this. I have also tried using:

Just a guess (didn't try that for called programs but for other Tk-internal
tasks):

Assign a cyclic task to the widget:

$wi_data->repeat(1000,\&cyclictasks);

In sub "cyclictasks" you write:

$wi_data->update;


Maybe this helps.

Cheers,
Detlef.

--
D. Marxsen, TD&DS GmbH
detlef.marxsen@tdds-gmbz.de (replace z with h, spam protection)

On Tue, 23 Nov 2004 21:18:26 +0100, David Herbison <dh123.ml@gmx.net>
wrote:

>Hi,
>
>I have a set of perl scripts which are usually called from the command
>line. I would like to make a simple GUI, which has buttons to start each
>of them, and a box where the STDOUT of each script is diplayed live. I
>came across this:
>
>button($but_frame, "Run",  "Run", sub { $output->insert('end', qx(
>script.pl ))});
>
>where $output is a read only listbox.
>
>which works, but the frame is updated only when the script.pl is
>finished, and the GUI is inactive during this. I have also tried using:
>
>tie(*STDOUT, 'Tk::Text', $output);
>
>This seems to work for the STDOUT of the GUI, but the STDOUT of the
>executed scripts lands in the xterm where the GUI was started.
>
>Any ideas are much appreciated.

The easiest way is with Tk::ExecuteCommand. This one opens it
in a separate toplevel window, but you can get to the subwidgets
of execute command and put them anywhwere.

#!/usr/bin/perl -w
use Tk;
use Tk::ExecuteCommand;
use Tk::widgets qw/LabEntry/;
use strict;

my $mw = MainWindow->new;

my $top = $mw->Toplevel;
$top->withdraw;

my $ec = $top->ExecuteCommand(
-command    => '',
-entryWidth => 50,
-height     => 10,
-label      => '',
-text       => 'Execute',
)->pack;
$ec->configure(-command => 'date; sleep 10; date');

my $button = $mw->Button(-text =>'Do_it',
-background =>'hotpink',
-command => sub{ $top->deiconify;
$top->raise;
$ec->execute_command;
$top->withdraw},
)->pack;

MainLoop;
__END__

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

David Herbison wrote:
> Hi,
>
> I have a set of perl scripts which are usually called from the command
> line. I would like to make a simple GUI, which has buttons to start each
> of them, and a box where the STDOUT of each script is diplayed live. I
> came across this:
>
> button($but_frame, "Run",  "Run", sub { $output->insert('end', qx(
> script.pl ))});
>
> where $output is a read only listbox.
>
> which works, but the frame is updated only when the script.pl is
> finished, and the GUI is inactive during this. I have also tried using:
>
> tie(*STDOUT, 'Tk::Text', $output);
>
> This seems to work for the STDOUT of the GUI, but the STDOUT of the
> executed scripts lands in the xterm where the GUI was started.
>
> Any ideas are much appreciated.
>
> David.
You can use Tk::ROTxt and Tk::IO (not tested):

$rotxt=$tl->Scrolled('ROText',
-scrollbars => 'se',
-wrap => 'none',
)->pack();
# now init the subrocess
$fh = Tk::IO->new(-linecommand => sub {$rotxt->insert("end", @_);});
$fh->exec("script.pl");

If you want to wait for the subprocess (and you should to not produce
zombies) you can use:

$ret=$fh->wait();

HTH

-Eyck

If any of the other suggestions work for you then you can skip this.
However, I thought that I heard that Tk::ExecuteCommand, on Windows, won't
print the contents of STDOUT until the 'executed script' completes.  ..and I
was not been able to get Tk::IO to recognize my exec script (but I did not
try hard due to the comments in the docs).

However, I do have a solution, that works on windows and writes the STDOUT
to a Tk text widget in real time.  The solution involves creating a child
process using Win32::Process::Create and using sockets to communicate
between the processes.  The child process runs the 'executed script' using
system($command).  Within the child process I redirect the SDTOUT to the
sockets filehandle.  The net effect is that, as writes occur to STDOUT (and
STDERR), they will appear in a text window in the calling process.

If this seems useful to others, then I can turn it into a cpan module.  I
just got it working and the code is NOT ready for prime time, but if you
like I can post what I have here, to give you some ideas.  It is a couple
hundred LOC.

Chris



"David Herbison" <dh123.ml@gmx.net> wrote in message
news:co0617$85o$1@online.de...
> Hi,
>
> I have a set of perl scripts which are usually called from the command
> line. I would like to make a simple GUI, which has buttons to start each
> of them, and a box where the STDOUT of each script is diplayed live. I
> came across this:
>
> button($but_frame, "Run",  "Run", sub { $output->insert('end', qx(
> script.pl ))});
>
> where $output is a read only listbox.
>
> which works, but the frame is updated only when the script.pl is
> finished, and the GUI is inactive during this. I have also tried using:
>
> tie(*STDOUT, 'Tk::Text', $output);
>
> This seems to work for the STDOUT of the GUI, but the STDOUT of the
> executed scripts lands in the xterm where the GUI was started.
>
> Any ideas are much appreciated.
>
> David.