Perl: It's not just for Unix anymore

Unix and Mac OS actually have a number of traits in common, although these may not be immediately obvious on casual observation. Both systems, for example, share a certain elegance and consistency. Users know what to expect (and are disturbed when something "feels wrong"). Both systems have devoted user communities, which frequently overlap.

Both Mac OS and Unix share a strong commitment to interoperability and the Internet. Either can run Web browsers, as well as FTP, Telnet, and X Windows clients. Either can function as an FTP or Web server. Both systems possess excellent text and code-editing tools (these are included with Unix systems; you'll need to go find them for Mac OS).

Unix and Mac OS also have quite different (yet complementary) natures. Unix is inherently text based, while the Macintosh relies upon its GUI, windows, and mouse. Unix users expect to do a lot of typing; Macintosh users do a lot of clicking and dragging. Unix is command (word) oriented, while the Mac OS is graphical (icon) oriented. A Unix user is well used to the concepts of current directory, pathnames, file permissions, and command line arguments. On the Mac OS, these are rarely-used concepts, foreign to most users.

Unix users have also built up a culture of Open Source software over the years, from the GNU project to the Linux, and BSD efforts, involving many popular packages. This culture has not been as prevalent in the Macintosh environment, where shareware (closed source) is more the order of the day. There have been a few exceptions, however: Gzip, TeX, Perl, Python, Tcl, and Telnet come readily to mind, as do LinuxPPC and NetBSD releases for Macintosh. More recently, Apple's MkLinux and Darwin efforts show a newly enlightened corporate attitude towards Open Source software! However, these are still the exceptions rather than the norm (and notably, these all represent ports of Unix Open Source software).

How does Perl fit in to the Mac environment?

It may surprise you to learn that Perl (MacPerl) fits in quite well. Because Perl was written to be a largely self-contained language (unlike the Unix shell, for example, which draws on many external programs), Perl functions surprisingly well in an environment devoid of familiar Unix tools. Under Mac OS, there is no shell, no awk, no grep, no sed. Emulations of cat, sum, join, and similar utilities exist, but they are pale comparisons. The Find utility is a different beast altogether.

Once within MacPerl, however, a Perl programmer can feel very comfortable. No rm command? Use unlink. No date? Use localtime. Regular expressions are there; files are easily opened and closed. Aliases approximate symbolic links. Folders act just like directories. The pathnames are a little strange, but it's not difficult to adjust.

MacPerl helps bridge the gap between the Macintosh as "user appliance" and the Macintosh as "power tool". MacPerl also helps Mac OS to interact with other operating systems, such as Unix, to create powerful, multi-faceted work environments; the whole is greater than the sum of its parts.

MacPerl can be used to script the usually-interactive Macintosh environment, making batch processing of data much easier (or possible!). MacPerl CGI scripts allow Mac OS applications to interact with Web pages. MacPerl can be used to write "user-friendly" mini-applications that take advantage of the expected Mac OS Look and Feel.

MacPerl can interact with AppleScript (Apple's Mac OS scripting language) to allow an even wider range of automation possibilities. For many programmers, used to algebraic languages, AppleScript is less powerful and more cumbersome than we would like; MacPerl reduces the amount of time a script must spend in the AppleScript realm, while augmenting the capabilities AppleScript possesses for controlling Mac applications.

Let's start with who might be a likely candidate for using MacPerl:

• A Unix programmer who also has a Macintosh
• Unix programmer who doesn't yet have a Mac
  (get one after you read this :-)
• A Mac power-user - interested in more power, learning to program
• A Web page designer - better tools, try things out
• A Network administrator - interested in a "secure network appliance"

One of the things the Macintosh excels at is what we'll call "Security Through Stupidity". That is, it's harder to break in if there's no-one to answer the door. Mac OS has no concept of login, minimalist permission schemes, and no shell. While it is possible to set up a Macintosh as an FTP server (and possible to leave the door wide open and the jewels on the kitchen table), it's also pretty easy not to.

Consider a nice, secure Macintosh, sitting on the outside of your firewall, accepting requests to its web server. It can pass those requests through the firewall to a Unix server, but even if the Macintosh is compromised, the bad guys still don't have access to your internal network (or your password file).

Consider, for example, the possibilities inherent in using MacPerl for CGI scripting, using MacPerl sockets to open communications to the programs on the Unix servers. MacPerl has more Socket families than Unix Perl. Additionally, there is a function, Choose(), which allows the programmer to interactively specify addresses or file names.

Even if your application doesn't lend itself well to running on the Macintosh, the MacPerl environment makes a terrific development and test environment. Even scripts that call unimplemented Perl functions can be edited directly from an FTP server with a Mac text editor (such as BBEdit or Alpha), syntax checked under MacPerl, then saved back to the FTP server and run via telnet or X. (Save a copy on the Macintosh for a cheap backup solution!).

There are gotchas, of course...

While concepts such as current directory, pathnames, and permissions are not commonly considered by most Macintosh users, they were not foreign to the Mac OS designers. Most of the "standard" Perl functions work; a few have missing features. There are a few differences, however, that can trap the unwary programmer. Many of these were covered in last month's column (http://www.perlmonth.com/columns/mac_perl/mac_perl.html?issue=2).

Pathname construction can be unusual and requires some "porting effort". Unlike Unix, Mac OS volumes (partitions) do not share a common "root". The Mac OS colon (:) is approximately equivalent to the Unix slash (/), but there are some significant difference in usage. Also, file names are case-insensitive (though case-preserving) and frequently include non-ASCII characters (and spaces!).

Many Mac OS documents also include non-ASCII or "extended" ASCII characters such as bullets and similar oddities not commonly seen in Unix text. Some of these are used for special glyphs (e.g., mathematical symbols); others encode meta-information for word processors, etc.

Permissions, of course, don't have much place under Mac OS; functions such as mkdir() require a mode but essentially ignore whatever mode they're given. Many other Unixisms, including links and long file names, are either radically different or unavailable on the standard Mac OS file system. Subtle differences between aliases and symbolic links may cause confusion under certain circumstances.

Although backquotes and system() are essentially off limits, a small number of common idioms, such as `pwd` and `hostname`, are emulated. (in a recent discussion at the Usenix Technical Conference, a Unix Perl programmer expressed great shock and dismay at the MacPerl emulation of `pwd`; obviously, not everyone thinks this emulation is a "good thing"!)

Happily, Perl is so rich in functionality that system() is rarely needed (with a little thought and judicious reading of the documentation!). In cases where calling another application might be necessary, MacPerl's hooks into AppleScript, ToolServer, or modules such as Mac::Apps::Launch and Mac::Glue will probably be sufficient to get the job done (more on these in future columns).

OK, so you can program a Macintosh. Why should you?

For one thing, because the Macintosh is a pretty neat environment. Unlike Unix, which grew up in a text-based, command-line driven world, and had a GUI interface (X) dropped in almost as an afterthought, the Macintosh was designed from the outset with the user-interface as its outstanding feature. Macintosh applications take full advantage of this, and the newest Mac OS 8.x features take this even farther.

Take, for example, the subject of text editors. Mac text editors such as Alpha and BBEdit support language-sensitive text coloring, extension mechanisms, drag-and-drop editing, multiple levels of undo, integrated regular expression engines, interactive search/replace and diff comparison/merging, editing of files on FTP servers, HTML tools, and other powerful features.

Even the simple day-to-day work environment can be improved by drag & drop editing in telnet windows, email clients that support rich text and clickable URLs, and multiple screen support where windows can be dragged from screen to screen with ease.

MacPerl takes full advantage of this environment. The MacPerl application provides an integrated edit / check / run / debug environment. If a script produces a syntax or runtime error, the offending line will often be instantly highlighted in the associated script. If not, select Jump To... from the Edit menu.

Depending upon how you've set up your environment, MacPerl provides a link directly to your favorite text editor. You can take full advantage of the tools provided by the editor environment, then send the script back to MacPerl to run. Changes made to the editor's copy of a script are instantly reflected in MacPerl's copy as well!

The MacPerl coding environment is so well integrated we've even had a comment from a Windows user asking if a similar Perl environment was available for his platform (he couldn't quite justify the purchase of a Macintosh simply to run MacPerl :-)

There must be something that isn't perfect.

Well, yes, there are a few small problems. For one thing, the Macintosh is not as inherently stable as most Unix platforms (although it gets better with each release). A Macintosh server should be running the latest system software, the minimal set of system extensions (INITs), and no applications unrelated to its role as a server.

You'll need to take some care with permissions. Mac OS gets its permissions from filesharing; these are less complete than Unix permissions and may take a little getting used to. Also, if File Sharing gets turned off by accident, services such as FTP and Web server capability will mysteriously stop.

And, unfortunately, Mac OS has minimal memory protection. Thus, viruses and system crashes are still an issue; the good news is that there are several very good (freeware and commercial) virus checkers available. And system crashes are becoming less intrusive (it is now possible to lose the Finder and keep running).

Obviously using the Macintosh as a server will take some thought, but we think the experiment will prove worthwhile. Use of the Macintosh as a development machine is highly recommended. You can still use the Unix tools (via X or telnet windows) but you will also have added a large collection of graphical, drag&drop, point and click tools to your portfolio. (Mac)Perl is one of the most interesting of those tools.

References:

Alpha is a shareware text editor for the Macintosh.

BBEdit is a commercial text editor for the Macintosh. A freeware version, BBEdit Lite, is also available.

Information on the Usenix Advanced Computing Systems Association is available at www.usenix.org

Information about the Mac::Apps and Mac::Glue modules can be found on Chris Nandor's web pages at http://pudge.net/macperl/.

Read more about Apple's Open Source projects: MkLinux (www.mklinux.apple.com) and Darwin ( www.publicsource.apple.com)