Perl Under Mac OS

Compared to Unix and Windows, Mac OS has one significant missing feature: it has
no command line interface. Mac OS is a 100 percent windowed GUI environment.
This presents some potential problems when we consider the methods already
suggested for running Perl programs.
The solution is a separate “development environment.” The MacPerl application
supports both the execution of Perl scripts and the creation of the scripts in the first
place. In addition to direct access to the execution process (scripts can be started and
stopped from menus and key combinations), MacPerl also permits you interactive use
of the Perl debugger in a familiar environment, and complete control of the environment
in which the scripts are executed.
Quite aside from the simple interface problem, there are also underlying differences
between text file formats, the value of the epoch used for dates and times, and even the
supported commands and functions. There are ways of getting around these problems,
both using your own Perl scripts and modifications and using a number of modules
that are supplied as standard with the MacPerl application.
The current version of MacPerl is based on v5.004 of Perl, which makes it a couple
of years old. Although the developer, Matthias Neeracher, has promised to work on a
new version, there is currently no set date for a Perl 5.6 release. In fact, it’s possible that
MacPerl may not be updated until Perl 6 is released toward the end of 2001.Repository URL
ActiveState http://www.activestate.com/packages
Jan Krynicky http://jenda.krynicky.cz/perl
Roth Consulting http://www.roth.net/perl/packages/
Achim Bohnet http://www.xray.mpe.mpg.de/~ach/prk/ppm
RTO http://rto.dk/packages/
Table 2-2. PPM RepositoriesFor those of you interested in developing with Perl under Mac OS X, you’ll be pleased
to hear that Mac OS X’s Unix layer is used to provide the same basic functionality as
any Unix distribution. In fact, Mac OS X actually comes with Perl installed as standard.
Installation
Perl is available in a number of different guises, depending on what you want to do
with it and how extensible and expandable you want the support modules to be. The
basic distribution, “appl”, includes the MacPerl binary, all the Perl and MacPerl libraries
and modules, and the documentation. The “tool” distribution works with MPW (the
Macintosh Programmer’sWorkshop), allowing you to develop and release Perl programs
that are part of a larger overall application while presenting you with the same interface
and development environment you use for C/C++ and Pascal Mac applications. Because
MacPerl provides an almost transparent interface to the underlying Mac toolbox, you
can use Perl and C/C++/Pascal programs and code interchangeably. The source, in the
“src” distribution, including all of the toolbox interfaces, is also available.
Installing the application is a case of downloading and decompressing the installer,
and then double-clicking on the installer application. This will install all the modules,
application, and documentation you need to start programming in Perl. Starting MacPerl
is a simple case of double-clicking on the application.
Executing Scripts
Perl scripts are identified using the Mac OS Creator and Type codes. The MacPerl
environment automatically sets this information when you save the script. In fact,
MacPerl specifies three basic formats for running scripts and one additional format
for use with Mac-based web servers. The different formats are outlined in Table 2-3.File Type Description
Droplet A droplet is a mini-application that consists of the original
Perl script and a small amount of glue code that uses Apple
events to start MacPerl, if it is not already running, and then
executes the script. Using droplets is the recommended
method for distributing MacPerl scripts.
To save a script as a droplet, go to Save As under the File
menu, and choose Droplet in the file type pop-up at the
bottom of the file dialog box.
Files dragged and dropped onto a droplet’s icon in the
Finder have their names passed to the script as arguments
(within @ARGV).
If you plan on distributing your scripts to other people,
droplets require that the destination users have MacPerl
already installed. This might make initial distributions large
(about 800K), although further updates should be smaller.
Table 2-3. MacPerl Script TypesFile Type Description
Stand-alone applications A stand-alone application creates a file composed of the Perl
application and the script and related modules. This creates a
single, “double-clickable” application that runs and executes
your script.
This can be a great solution if you want to provide a single-file
solution for a client, or if you want to save clients the task of
installing MacPerl on their machines.
However, this is still an interpreted version. The script is
not compiled into an executable, just bundled with the Perl
interpreter into a single file.
Plain text file A plain text file can be opened within the MacPerl environment
and executed as a Perl script. Make sure that if the script has
come from another platform, the script is in Mac OS text format.
These files will not automatically execute when you doubleclick
them. They open either the built-in editor within MacPerl
or the editor you usually use for editing text files (for example,
SimpleText, BBEdit, or emacs).
CGI Script This creates a script suitable for execution under many
Mac-specific web servers, including the one supported
by Apple’s AppleShare IP 6.0.
Table 2-3. MacPerl Script Types (continued)When a script is executing, STDIN, STDOUT, and STDERR are supported directly
within the MacPerl environment. If you want to introduce information on a “command
line” (other than files, if you are using a droplet), you will need to use the Mac-specific
toolbox modules and functions to request the information from the user.
Installing Third-Party Modules
Installation of third-party modules under MacPerl is complicated by the lack of either
standard development tools or a command-line environment that would enable you to
execute the normal Perl makefiles for make tools.
Scripts that rely on external modules, such as those from CPAN (especially those
that require C source code to be compiled), may cause difficulties, not all of which can
be easily overcome. The process for installing a third-party module is as follows:
1. Download and then extract the module. Most modules are supplied as a gzipped
tar file. You can either use the individual tools, MacGzip and suntar, to extract
the file, or use Aladdin System’s Stuffit Expander with the Expander Extensions.Whichever application set you use, remember to switch line-feed conversion
on. This will convert the Unix-style Perl scripts into Macintosh text files, which
will be correctly parsed by the MacPerl processor.
2. Read the documentation to determine whether the module or any modules on
which it relies use XS or C source code. If they do, it’s probably best to forget
about using the module. If you have access to the MPW toolkit, you may be
able to compile the extension, but success is not guaranteed. You can also ask
another MacPerl user, via the MacPerl mailing list, to compile it for you.
3. Ignore the Makefile.PL file. Although it might run, it will probably report an
error like this:
# On MacOS, we need to build under the Perl source directory or
have the MacPerl SDK installed in the MacPerl folder.
Ignore it, because you need to install the Perl modules manually. Even if the
Makefile.PL runs successfully, it will generate a makefile that you can’t use on
the Mac without the addition of some special tools!
4. Create a new folder (if you don’t already have one) to hold your site-specific
and contributed modules. This is usually located in $ENV{MACPERL}sitelib:,
although you can create it anywhere, as long as you add the directory to the
@INC variable via the MacPerl application preferences or use the use lib
pragma within a script.
Remember to create a proper directory structure if you are installing a
hierarchical module. For example, when installing Net::FTP, you need to
install the FTP.pm module into a subdirectory called Net, right below the
site_perl or alternative installation location.
5. Copy across the individual Perl modules to the new directory. If the modules
follow a structure, copy across all the directories and subdirectories.
6. Once the modules are copied across, try using the following script, which will
automatically split the installed module, suitable for autoloading:
use AutoSplit;
my $instdir = "$ENV{MACPERL}site_perl";
autosplit("$dir:Module.pm", "$dir:auto", 0, 1, 1);
Change the $instdir and module names accordingly. See Appendix B for
more details on the AutoSplit module.
7. Once the module is installed, try running one of the test programs, or write a
small script to use one of the modules you have installed. Check the MacPerl
error window. If you get an error like this,
# Illegal character \012 (carriage return).
File 'Midkemia:MacPerl ƒ:site_perl:Net:DNS:Header.pm'; Line 1
# (Maybe you didn't strip carriage returns after a network transfer?)then the file still has Unix-style line feeds in it. You can use BBEdit or a similar
application to convert these to Macintosh text. Alternatively, you could write a
Perl script to do it!