OptiPerl has massive amount of tools to create CGI scripts; however many tools exists solely for console script.


  • Arguments (command line parameters) can be specified from Run / Arguments. Also is a combo box with previous arguments you had used. Note the argument can be added to the combo box by selecting menu Query / Add values. If you are using OptiPerl only for console work, we recommend customizing the menu, moving this item to the run menu and removing the "query" menu and toolbar.


icon_exclaim The array @ARGV contains the command-line arguments intended for the script. Command line parameters cannot be used for CGI scripts.


  • Setting the Starting Path from Run / Select starting path.


icon_exclaim The starting path affects only console scripts.


  • Debugging. The arguments are fed to the script when starting the debugger.


  • Opening / Saving to remote locations can save you from a lot of work if the script is intended to run on another machine. Also if it is actually possible to run the script on your machine for developing purposes, don't forget about the version converter that is used automatically.


If the console script cannot be run in windows, then create a custom tool to invoke it some way for testing purposes.


  • Running. You can run in a dos - console box. When selecting menu Run / Run in console, you first get a parameter dialog that prompts you for extra parameters to run with.


The default parameter (and the simplest and necessary) is


%pathsn% %ARGV%


%pathsn% gets replaced with the scripts path as a short name

%ARGV% gets replaced with what you entered in the Arguments.

The path to perl is appended automatically in the front.


So if you have a script named c:\perl\test.pl and you have entered the arguments "-a -b" then the above would run perl in a console window like this:


perl c:\perl\test.pl -a -b


You don't have to put %pathsn% at all. You can replace with any parameter you want, even create one-liner programs extremely quickly. For example try


-e "print 'Hello';"


If you are running in the console and the output is large, you might need to pause on each page. To do this, after pressing "Run in Console", enter in the dialog box:


%pathsn% %ARGV% | more


This way after each page of output you will be prompted to press a key for the next page.


  • Running in the browser. If you are only interested only in the text output, then select Run in Browser, and have the option Server / Run with Server disabled. You will be able to see the output in the "Text" tab of the web browser. Disregard all other tabs. If the script also expects input from <STDIN>, you can enter the text you want in the "Send" edit box of the webbrowser. This will send the text with a CRLF at the end. The edit box also accepts \n \t \r and the special \z which is CTRL-Z (ascii 26) usually used to terminate input.


  • Feeding to <STDIN> automatically. This can only be done when running in the browser. Open the query editor, and enable the "POST" method. In the POST tab, select "Raw" encoding and enter the string that should be fed in the "Manual" edit box. Again \n \t \r and the special \z are accepted, plus \f<filename> to send an entire file (right click for an open file dialog). For example you can enter:




This will send the file c:\input.txt and the character CTRL-Z to end it.

Note that the POST method is used of course for CGI, but by using Raw "encoding" it can really help automation of testing console scripts. The data is fed also if you start the debugger.


icon_exclaim Use the "Run in browser" feature! Don't get mixed up with the word "Browser" which reminds of CGI. The text tab of the Browser window will be an exact representation of the output (a pipe is opened for this). Also the fact that you can automate sending many lines to <STDIN> makes it a big help (you cannot do this in a console window). If for example the script makes 4 questions before output, enter something like this in the "POST" method:




Don't forget that the POST method for CGI scripts works the same way! Only difference is that the data gets URL encoded first and headers are sent telling the script how much data to expect.


icon_idea If you want to test the script with many different parameters, it might be difficult to change each time the Arguments from the Run menu. Instead, enter them each time in the Parameter list removing %ARGV%. Or do a little of both, put some standard arguments in Run / Arguments and play with the rest in the parameter dialog each time you run.


icon_idea To increase productivity, move the Arguments combo box from the Run menu to a toolbar you create next to the editor.


icon_idea Another interesting thing to do, for the more advanced programmer. Notice that you can also use the %f<filename>% tag in the parameters, like for example %f<c:\test\testparams.txt>%. When you run, the text of the file testparams.txt will be placed as command line arguments! Make sure that the text has not EOL characters.


icon_idea If your scripts also depend on their location on the drive, because they use absolute paths, see "Using absolute paths".


Top  Previous  Next