Table of Contents
It is often necessary to execute a Biferno script independently from the Web server, i.e. by executing a command on the machine where Biferno is running rather than by invoking a URL from a browser. An example is a script that creates or recreates SQL tables, or a script that fills a database using data retrieved from disk by searching in a directory at regular predefined time intervals.
The technique used to run a script locally changes depending on the operating system used, and we will introduce the topic by first mentioning a number of fundamental issues.
When launching a script locally the concept of "server root" is no longer
meaningful and therefore the serverInfo.root call returns an empty
string. Our script should not depend on the value of the server root, and
actually the empty string can be used to recognize that the script is being
run locally. Furthermore all file paths starting with '/' are no longer
valid, as the concept of "starting from server root" is no longer valid. A
script that should support both local and Web invocation can implement a
parametric path using a SERVER_ROOT variable that will simply
be assigned the value of the desired start path in case of local execution.
Another remarkable change is that the HTML code in the script output is filtered and the remaining text is sent directly to the console (see details about the different operating systems in the following) to allow local execution of scripts developed for Web access. Three more important differences are the following:
Normally the text sent in output by a Web script is buffered and
sent in one reply to the client, i.e. the entire output page is buffered.
When a script is executed locally, after each call to the print function
(or $, $$) the text to be printed is sent immediately to the
console.
No access control is performed when a script is run locally, i.e.
the value of the ACCESS_CONTROL application variable is ignored. Notice
that the same rules with respect to scripts belonging to an application
hold for Web and for local scripts.
Execution of a local script requires a new Biferno process to be started and therefore application variables are reinitialized using the Biferno.config file. This implies that modifications to these variables performed after Biferno startup are not visible to local scripts, but only to the Biferno process serving Web requests.
With these considerations in mind, let's review what happens in the different operating systems.
A local script is executed on Unix by typing the bifernod command followed
by the -f option and by the path of the file containing
the script. The path can be absolute or relative to the current directory.
The command:
bifernod -f /usr/local/myscript/dosomething.bfr?a=3&b=5
executes the dosomething.bfr script in the
/usr/local/myscript folder and passes the parameters
a=3 and b=5 (notice that the absolute
path should not start by file://).
To schedule a script on Unix the cron system utility is used. A complete
discussion of cron can be found in the Unix system documentation, see e.g.
this
resource. As an example, consider the line:
17 8 * * * root bifernod -f /usr/local/myscript/dosomething.bfr?a=3&b=5
When added in the cron configuration file (usually
/etc/crontab,
/private/etc/crontab on MacOSX), the line executes the
dosomething.bfr script (as the root user) in the
/usr/local/myscript folder every day at 8:17, and
passes the parameters a=3 and b=5 to
the script.
On MacOSX the ACGI version of Biferno (Biferno.acgi)
is also available and provides an alternative (see also Section 3, “MacOS Classic”).
A local script is launched on Windows by executing the
Biferno.exe application from a terminal window
followed by the -f option and by the path of the file
containing the script. The path can be absolute or relative to the current
directory. The command:
C:\Applications\Biferno.exe -f /C/MyScripts/dosomething.bfr?a=3&b=5
executes the dosomething.bfr script in the
C:\MyScripts folder and passes the parameters
a=3 and b=5. Notice that the
application path follows Windows path rules, while the script path can follow native rules (C:\MyScripts...) or
Biferno rules (except for the fact that in this case the absolute path should not start
by file://).
To schedule a script on Windows we can use the Scheduled Tasks application in the Control Panel to automatically launch a Windows command similar to the one above. The Windows system documentation provides additional details.
To execute a local script on MacOS we need the
Biferno.acgi application. This application has
the same functionality of the WebSTAR plug-in but runs as a separate
application (Application Common Gateway Interface). Actually, the
Biferno.acgi application could be used instead
of the plug-in by defining WebSTAR the corresponding
ACTION and linking the .bfr suffix
to the ACTION (see the WebSTAR documentation or the
documentation of your Web server for CGI and
ACTION/Suffix activation).
The use of the plug-in is preferred because the plug-in has better performances and is more suitable to handle the user load of a Web site. The cgi interface is useful for the execution of a local script.
The simplest way to execute a Biferno script on MacOS is to drag-and-drop
the .bfr file icon on the
Biferno.acgi application. The CGI will be
immediately launched (if inactive), the script executed and its output sent
to the CGI console. Alternatively, if the 'BFRN' (all
uppercase) creator has been defined for the text file containing the
script, a double click on the file will directly invoke
Biferno.acgi and execute the script.
The same can be achieved by choosing the item from the menu of the cgi application and specifying the file to be processed.
If we want to pass parameters to the script, it is necessary to implement a simple Applescript script that invokes the script file as if it were a URL. As an example consider the following AppleScript code:
property notification_indicator : false -- false to avoid dialog window
ignoring application responses -- avoid timeouts
tell application "MacHD:BifernoHome:Biferno.acgi"
open "MacHD:myscript:dosomething.bfr?a=3&b=5"
end tell
end ignoring
The code invokes the dosomething.bfr script in the
MacHD:myscript folder and passes the parameters
a=3 and b=5 (we assume the
Biferno.acgi application is in the
MacHD:BifernoHome folder).
Alternatively the following code can also be used:
property notification_indicator : false -- avoid dialog window ignoring application responses -- avoid timeouts tell application "Finder" activate select file "dosomething.bfr" of folder "myscript" of startup disk open selection end tell end ignoring
This technique can be also used to schedule the execution of a script. It will suffice to periodically execute the script using one of the many Applescript scheduling utilities available for the MacOS platform, see e.g. the iDo Script Scheduler from Sophisticated Circuits, www.sophisticated.com.