Running scripts normally without using shell?

[newbie]

I have written a very simple script which was a part of chapter 1 of my first Perl lesson. The script let's me type 1 sentence and then the script prints that sentence again. When I double click on the script then my perl interpreter (ActivePerl 5.8.8 Build 819) executes the script but the dos window is immediatly gone afterwards! I want to see the result, but in a split second it is gone. Is there a possibility for executing Perl scripts so that the result can be normally viewed? My manual says that there is a way but only by using the shell, now that would be very old fashioned for such a sophisticated language.

The manual said:
However, the window containing the output will disappear as soon as the program has finished (try it!), and you won't be able to see what's happened, so I encourage you to use the shell instead.

What is the absolute best Perl interpreter, Visual Perl creator etcetera, whatever the cost. I am looking for simplicity. (windows xp)

[Albannach]

If it's simplicity you want, just make this the last line of your script:

<STDIN>;

This early in your lessons it is probably sufficient to say that this tells perl to wait for something to be typed, and that will have the effect of holding the window open for you. When you have finished admiring your output, just hit Enter, thereby giving the program some input and the window will close. There are lots of other ways to do what you want, like use one of many GUI toolkits or IDEs, but this is certainly simple and cheap!

Besides, I think you may find after some time that despite the shell being "old fashioned", it is often a far better environment to work in!

[GrandFather]

I don't know what "absolute best Perl interpreter" means, but an answer to the question I think you are asking is: use ActiveState's Komodo IDE. There is a modest cost for "home use", but if you are moderately serious about Perl (or any of the other languages it supports),then it is well worth the investment.

Its solution to your immediate problem (How do I see my output) is two fold: there is an output pane that shows the output from the script you are running and that stays around afterwards, and you may have Komodo open a console window when you run your script in which you can interact with the running script as you would from a commandline.

[blazar]

My manual says that there is a way but only by using the shell, now that would be very old fashioned for such a sophisticated language.

Notwithstanding how "old fashioned" using the shell may seem to you, or even actually be, a CLI shell is still the best way, and the most efficient one, for one to work in many circumstances, and in fact the "sophistication" of a language like Perl has nothing to do with the ability of the OS it's run on to call it by clicking on a fancy icon in a GUI, indeed "simplicity is the essence of happiness" and believe it or not advanced users tend to prefer shell based environments. Actually there are now desktop environments for *NIX osen which imitate and even go far beyond Windows' bells-and-whistles-ness, but even there people often has a bunch of terminal emulators open to do, well, stuff. The rationale being, it's had to think you can get out more and more quickly out of a mouse with three or so buttons than from a keyboard with one hundred and odd...

[jbert]

There are two ways (at least) of running processes on windows. In one, the process has the "standard" input, output and error streams (STDIN, STDOUT and STDERR). These have to have somewhere to go, and so windows has them run within a console window.

This mode most closely mimics the Unix background of perl's heritage and so this is the default behaviour of the perl interpreter (perl.exe) on windows.

The other way of running a process on windows is for it to have its own window handling function (WinMain). In this case, the process doesn't have an associated console window (or STDIN, STDOUT and STDERR) and is able to create its own windows if it chooses. This is what the vast majority of 'normal' windows applications do.

You can run your perl script in this second form by using the "wperl.exe" perl interpreter, which should be in the same place as your "perl.exe".

But note - if you do this then you won't have any windows unless you create them and your script won't have the input output streams. i.e. you won't see anything (but if your script does other things - such as create files - you'll see the effects).

So how do you create windows? Well, now you're in the territory of GUI programming. You can either try and drive the native windows UI via the Win32:: modules (which will be difficult and unrewarding I think) or use a GUI toolkit. The main choices of toolkit I know of are Gtk+, QT, WxWindows and Tk.

All of these are cross-platform, which means your script should work with minimal changes on Linux and the Mac, which is always nice.

Choosing between these GUI toolkits and their pros and cons is the subject of a node I now intend to create.

[blazar]

The other way of running a process on windows is for it to have its own window handling function (WinMain). In this case, the process doesn't have an associated console window (or STDIN, STDOUT and STDERR) and is able to create its own windows if it chooses. This is what the vast majority of 'normal' windows applications do.

This is slightly misleading. I'm no expert at all but it appears that a .exe header has "slots" for some kinds of executable breeds, to be handled by separated subsystems. One of these is CONSOLE which provides a console to "attach" STDIN, STDOUT and STDERR, and another one is WINDOWS, which does not provide it, for applications that do not need it. But applications of both types may create their own window(s). Indeed newbies at Tk and other toolkits in Win* envs often get annoyed by the pop-up console they get on clicking on their script, and then they're rightly pointed to wperl.exe, however there may well be a console application with a GUI part, although that's simply not common:

#!/usr/bin/perl -l

use strict;
use warnings;
use Tk;

{
    print "Do you want to press some buttons? (Y/N) [Y]";
    chomp(my $in=<STDIN>);
    $in='y' if $in eq '';
    my $cmd={ y => sub {}, n => sub {
        die "So long then...\n";
    } }->{lc $in} || redo;
    $cmd->();
}

my $mw=MainWindow->new;
$mw->title('Button 2 STDOUT example');

for my $msg (qw/foo bar baz/) {
    $mw->Button(-text => "Print '$msg' to STDOUT",
        -command => sub {print $msg})->pack
}
  
$mw->Button(-text => 'Exit GUI',
    -command => [$mw => 'destroy'])->pack;

MainLoop;

print "It has been unforgettable!";

__END__

You can run your perl script in this second form by using the "wperl.exe" perl interpreter, which should be in the same place as your "perl.exe".

Indeed I believe wperl.exe is "built" by exetype.bat, also distributed with ActivePerl. The latter in turn is just a Perl script itself and a quick look at it reveals it just changes the value of a few bits in the executable it is passed.

[lyklev]

Mouse-clicking generation? Obviously, the win32 generation does not know how to appreciate a nice shell...

Maybe not the best, but definately the cheapest is:

cmd.exe

(From the start menu, click "Run as..." and type "cmd")