Summary

Bridging the GUI to Command Line Gap: Hybrid Software

One final class of software we'll touch on in this chapter is a diverse group of commands, programs, and applications that we've taken to calling hybrid software. These programs bridge the gulf between the GUI and command line, bringing GUI interfaces to command-line tools or command-line access to traditionally GUI features. Hybrid software is one of the most interesting and potentially enabling aspects of Mac OS X, and currently seems to be one of the most overlooked as well. We hope we've convinced you by now that command-line software can be incredibly powerful, even if you might still have reservations regarding how user friendly it might be. Many hybrid applications bring the user-friendly graphical mode of interaction you're accustomed to under classic Mac OS, and under Mac OS X Aqua to command-line power and flexibility. Others bring Mac OS accessibility to the command line.

The range of applications possible is limited only by the combinations of command-line software that might be composed, which as you will continue to find throughout this book, is nearly endless. Because we can't hope to document everything available, we'll introduce you to the general concepts by covering the simple tools Apple has made available, an interesting application that lets you put a GUI interface on any command-line tool, and a large suite of tools that blend an old-favorite Mac OS text editor with a traditional Unix text-processing and publication system. The general concepts used in these pieces of software, such as the simple extension of functionality by adding additional command-line parameters to configuration files, should be of general use when you find software of this nature.

The Command Line and the Pasteboard (Clipboard): pbcopy, pbpaste

Of the tools that Apple has provided, pbcopy and pbpaste are two that are both subtle and interesting. These command-line tools interact with the same clipboard (or pasteboard, as it is being called under Mac OS X) that the GUI Copy/Paste menu actions and keyboard equivalents do. This allows you to move data back and forth between GUI tools and command-line applications with ease. The data is currently limited to textual data types (including formatted text), and EPS, which restricts the utility somewhat, but these commands still play an important role that cannot be accomplished by the traditional Copy and Paste menu actions. Specifically, these commands accept input on the command line's Standard Input, or write their output to the command line's Standard out, allowing them to be used in the construction of small automated programs (you'll learn more about scripting the shell in Chapter 15). The command documentation tables for pbcopy and pbpaste are shown in Tables 13.22 and 13.23, respectively.

Table 13.22. The Command Documentation Table for pbcopy

pbcopy	Copies data from STDIN into the clipboard/pasteboard.
pbcopy [-help] [-pboard <general|ruler|find|font>]
pbcopy places data from its standard input (STDIN) into the Mac OS X clipboard/pasteboard. Data is placed in the pasteboard as ASCII unless it starts with EPS or RTF headers, in which case it is placed as those datatypes.
Mac OS X supports multiple pasteboards (clipboards) for different data types. For more information on the different data types, see http://developer.apple.com/documentation/Cocoa/Conceptual/CopyandPaste/Concepts/DataTypes.html.
-help	Displays its only option, -help.
-pboard <board>	Specify the pasteboard to use. Options for <board> are general, ruler, find, and font.

Table 13.23. The Command Documentation Table for pbpaste

pbpaste	Writes textual data from the Mac OS X clipboard/pasteboard to STDOUT.
pbpaste -help
pbpaste [-pboard <general|ruler|find|font>] [-Prefer ascii|rtf|ps]
pbpaste pasts textual data from the clipboard/pasteboard to the command line via STDOUT. The -P option allows you to suggest a preferred output format but is not necessarily obeyed.
-Prefer rtf	Prefer output in rich text format if available.
-Prefer ps	Prefer output in encapsulated PostScript format if available.
-Prefer ascii	Prefer American Standard Code for Information Interchange (yes, that's what ASCII stands for) plain text format.
-pboard <board>	Specify the pasteboard to use. Options for <board> are general, ruler, find, and font.

Integrating GUI Tools and Command-Line Programs: TurboTool, ScriptGUI, gnuplot

There is a set of applications that is best described as integrating GUI tools and command-line programs. In some instances, you use a GUI to perform actions that you could perform at the command line. In other instances, you interact with a command-line tool and GUI tools. In this category, we will look at TurboTool, ScriptGUI, and gnuplot. You can use TurboTool for automation, ScriptGUI for running scripts in the Finder, and gnuplot for graphing.

Automation with TurboTool

Until you're comfortable with the material in Chapter 15 and have started to write your own shell scripts that can make good use of these, you might find the shareware package TurboTool from http://www.filewell.com/TurboTool/index.html to be more immediately gratifying (although it'll be more powerful, too, after you've mastered adding your own shell script functionality to it). This tool allows you to wrap GUI and drag-and-drop interfaces around a number of built-in functions, and even more powerfully, around command-line commands and scripts. Figures 13.1, 13.2, 13.3, and 13.4 show the four components of a TurboTool action that takes a screenshot of a window that you pick, extracts image data from the clipboard, resizes it 75%, and then writes it to disk as a JPEG file. You perform the action in the TurboTool interface, shown in Figure 13.5.

Figure 13.1. The TurboTool Action Inspector allows you to examine or build small functional components into complex actions. Here screencapture is used to capture a window.

Figure 13.2. The second component of the resize to 75% and save as JPEG action is the acquisition of a TIFF format file from data in the clipboard.

Figure 13.3. The third component is to query the user for a filename with which to save the final image.

Figure 13.4. The fourth component uses a command-line tool to execute the requested resize and save actions.

Figure 13.5. You can perform actions in the TurboTool window.

The first component, shown in Figure 13.1, uses screencapture to capture the window that you click on when you perform the action. The second component, shown in Figure 13.2, uses a built-in TurboTool action (TurboTool calls them atomics) to read image data from the clipboard, using Mac OS's built-in clipboard-conversion capability to extract a TIFF if possible. The third component, shown in Figure 13.3, pulls up a file-request type dialog in which you can enter a filename for the image and sets an internal TurboTool variable to the result so that the next step has a filename to save to. The final component, shown in Figure 13.4, is perhaps the most interesting. It executes a small shell script to perform the functionality of converting the data from the TIFF read from the clipboard into a JPEG and resizing it 75%.

You can perform any of these actions in the TurboTool interface. Select an action, click Perform Action, and then do anything the action requires of you. In this example, the snap 75% jpg action has an informational section noting that you need to install ImageMagick to perform the action, but it also provides a URL to ImageMagick. When you perform that action, you select what window you want to capture, and provide a name to save the file. Figure 13.5 shows the TurboTool interface after the snap 75% jpg action has been performed. The name of the file that was saved is shown toward the top.

Running Scripts in the Finder with ScriptGUI

ScriptGUI, available from http://www.scriptgui.com/, lets you run scripts in the Finder. You can use it on existing scripts or you can use its editor to create scripts.

We'll show a simple demonstration of using ScriptGUI to start that Java-based program Haploview, available from http://www.broad.mit.edu/mpg/haploview/index.php, which can be used for haplotype analysis.

Figure 13.6 shows the creation of our script, haploview, in ScriptGUI. You can click Run to run the script, or you can save it and then click Run. When you save your script, you can choose ScriptGUI Native, Plain Text, or Scriptlet, which saves the script as an application with an .app extension. No matter which format we choose, whenever we click on this script in the Finder, Haploview starts.

Figure 13.6. ScriptGUI can be used to run scripts in the Finder.

In this particular example, we could have named our script haploview.command, which would have allowed it to be able to start from the Finder. Clicking on haploview.command would start Terminal and run the script in it, which then starts Haploview.

Graphing with gnuplot

If you have ever been disappointed in the graphs that you have generated in Excel, you might want to consider gnuplot as an alternative. gnuplot is a free package available from http://sourceforge.net/projects/gnuplot. It is available for many platforms, including Unix and Windows, and for Mac OS X, you can download it as a .dmg file. gnuplot supports many output devices, including X11, AquaTerm, printers, epslatex, gif, pdf, png, and jpeg. You can find a wealth of documentation on gnuplot at http://gnuplot.sourceforge.net/. The .dmg file also includes documentation. It might take some time to learn the package, but you will be pleased with its results.

The version of gnuplot available for Mac OS X comes already capable of using X11 or AquaTerm as output devices. You can install gnuplot without either, but you will probably want to conveniently display the graphs you are generating, and having at least one of those interfaces available will be a must. Apple's X11 is sufficient for the X11 option. For more information on the X Window system, see Chapter 17, "Using X Window System Applications." If you would like to be able to display to an Aqua application, download AquaTerm, a graphics terminal for Mac OS X, from http://aquaterm.sourceforge.net/.

gnuplot installs in /usr/local/bin. You interact with gnuplot at the command line, but you can display output to either X11 or AquaTerm, among various other devices. In our simple example, we will plot sin(x). To see the result in the X11 interface, start the X11 application. At the command line, type gnuplot. Then at the gnuplot> prompt, type plot sin(x). Here is sample output from the terminal:

 [creampuf:~] joray% gnuplot         G N U P L O T         Version 4.0 patchlevel 0         last modified Thu Apr 15 14:44:22 CEST 2004         System: Darwin 7.5.0         Copyright (C) 1986 - 1993, 1998, 2004         Thomas Williams, Colin Kelley and many others         This is gnuplot version 4.0.  Please refer to the documentation         for command syntax changes.  The old syntax will be accepted         throughout the 4.0 series, but all save files use the new syntax.         Type `help` to access the on-line reference manual.         The gnuplot FAQ is available from                 http://www.gnuplot.info/faq/         Send comments and requests for help to                 <[e-mail]>         Send bugs, suggestions and mods to                 <[e-mail]> Terminal type set to 'x11' gnuplot> plot sin(x) 

To view results in AquaTerm instead, you can run gnuplot in either the Terminal or X11 applications. Before you run gnuplot, set the GNUTERM environment variable to aqua. For more information on environment variables, see Chapter 15.

If you are running bash, set the environment variable like this:

 creampuf:~ joray$ GNUTERM=aqua creampuf:~ joray$ export GNUTERM 

If you are running tcsh, set the environment variable like this:

 [creampuf:~] joray% setenv GNUTERM aqua 

After the environment variable has been set, start gnuplot and then run plot sin(x). When you start gnuplot, you will see a note that the terminal type is aqua.

As you might expect, you can also load files and display them using gnuplot. A site with some interesting gnuplot images is located at http://ayapin.film.s.dendai.ac.jp/~matuda/Gnuplot/pm3d.html. This site demonstrates the use of the palette-mapped 3D terminal, pm3d, which is now included as part of the gnuplot software. Not only does this site include some interesting images, but it also includes the files that were used to generate the images. Information on the pm3d software can be found on Dr. Petr Mikulik's site at http://www.sci.muni.cz/~mikulik/gnuplot.html.

Because we thought you might find an image from this site more interesting to view than sin(x), we slightly modified the file that was used for the turritella image at the bottom right of the first page at this site to display in X11 and AquaTerm. Figure 13.7 shows how the turritella looks in X11, and Figure 13.8 shows how it looks in AquaTerm.

Figure 13.7. Here we have slightly modified the turritella gnuplot file to display in Apple's X11 application.

Figure 13.8. Here we have slightly modified the turritella gnuplot file to display in AquaTerm.

Mixing and Matching to Text-Processing Perfection: AlphaX, OzTeX, and TeX

We've repeatedly written that one of the most significant benefits of the traditional Unix mindset and way of doing things is that it allows you to mix and match the components you need to suit the job you're doing, and your own personal way of working. As a final demonstration of how this benefit carries over to GUI applications in hybrid application suites, we want to mention the combination of AlphaX, OzTeX, and TeX, which together comprise what could be called a word processor.

Reading as far as you have in this book, you might find the notion of a word processor to be somewhat contrary to the "small programs, with specific functions" philosophy that we've been repeating with respect to Unix. In fact, this combination of software works unlike any other word processing application you're likely to be familiar with and fits the Unix philosophy quite well. In fact, it fits it so well that if you decide to try out this system, we almost guarantee that you'll experience some initial discomfort in trying to learn the new patterns of thinking required.

Perhaps the largest single item of culture shock that you'll find is that there is no WYSIWYG (What You See Is What You Get) interface to the formatting of your text. That's right the wonderfully convenient and powerful paradigm for content editing that Apple brought to light in 1984 with MacWrite, that what you see on the screen as you're editing, is what appears on the page when you print, is conspicuously absent from this system. And this is a GOOD thing! WYSIWYG editors revolutionized desktop document creation and turned an entire generation on to writing their own documents, creating their own content, and formatting it how they chose. It was a brilliant decision on Apple's part to foster this as the paradigm for the coming age of personal computing, and a wonderful enabling technology for those who want to create documents rich with personal style. Unfortunately, we aren't all born to be brilliant document formatters, and personal expressions of style aren't always the best way to clearly convey information. Worse, it seems rare that those who have important information and content to convey are also blessed with the necessary stylistic insights to convey that information clearly.

Working in the academic environments that we do, it's common for us to see people using traditional Macintosh or Windows word processors to write letters, papers, or books, who are expending as much effort on trying to format their document professionally as they are on writing the content of the document itself. This creates enormous inefficiency in the dissemination of knowledge. These people are students and faculty and are working hard to clearly and concisely capture their knowledge in written form, and are simultaneously being required by the WYSIWYG word processors to suddenly become professional typesetters if they want to have professional-looking output. This is an unreasonable burden, and one that I believe we, as computer users, willingly assume only because we've become accustomed to the apparent freedom that WYSIWYG editors appear to give by allowing us to endlessly tweak the visual presentation until it is "just so."

As you might imagine, the traditional Unix way of approaching the problem is rather different. Instead of requiring the author to become an expert typesetter, "word processing" in the TeX sense is based on the use of a typesetting program. In this system, the typesetting program itself is the expert typesetter, and the author is free to concentrate on the content. Of course, TeX is also sensitive to the notion that users do desire and deserve significant control over the formatting of their documents. To facilitate this, the author can provide local and global suggestions regarding the formatting to the typesetting program. This system actually provides considerably more control over the final formatting than WYSIWYG word processors do because the typesetter is in fact an interpreter for a programming language designed around the idea of formatting text, and the author has the option of exerting as much or as little control over the system's automated choices as she wants.

Without a doubt, this method of work requires a significant rearrangement of the way one approaches writing problems, and the sense that you're not in control can be irrationally disturbing, especially for someone long-accustomed to the WYSIWYG way. Your humble author came to TeX after having worked in the Unix world for several years, and I still found the transition to be difficult. I spent a long time resisting everyone's suggestions to stop fighting with the system, concentrate on my writing, and "let go" so that the system could do what it was designed to do. It took probably a year of working in TeX on a daily basis before I discovered that I was no longer fighting for control.

Having cleared that mental hurdle, however, I can safely say that I have no desire to ever return to WYSIWYG word processors for any serious writing. If clearly conveying information is the paramount concern for a document, I find it tremendously liberating to not have to worry about formatting, and to be able to concentrate on what I am writing rather than how it appears onscreen. The TeX system's expert typesetting rules almost always make good formatting choices, and I can override them in those specific instances where I am displeased with the final appearance of the result. Only if a document's physical layout is of similar importance to the content (such as with advertising, flyers, leaflets, and similar material), will I resort to a WYSIWYG editor (and even these documents could be accomplished with the TeX typesetting system if the investment in time to write the layout rules for an advertising flyer could be justified by its repeated use).

This having been explained, a short description is in order regarding how AlphaX, OzTeX, and TeX are interrelated in this Unix-style word processing suite.

• AlphaX, available from http://www.maths.mq.edu.au/~steffen/Alpha/AlphaX/, is a text editor. That is, it edits text. Not styled text, not text in different fonts, not text in different colors or sizes, just "plain old text" text. It's a Mac OS X incarnation of the venerable Alpha editor from the days of Mac OS. One of the neatest things about Alpha is that in spirit, it should have been a Unix application all along. Alpha, available in a number of variations on a number of platforms, is a text editor built out of a graphics-enabled scripting language. When you run Alpha, what you run is essentially a collection of scripts that cooperatively create a text-editing interface. If you're so inclined, you can edit and add to the scripts, changing the functionality of the editor to suit your particular needs.

  As a text editor, Alpha is oriented toward the editing of various types of programming languages, including the TeX and LaTeX typesetting languages. Conveniently, it provides a multitude of options for syntax highlighting in different languages and automatic insertion of assorted syntactic constructs. This allows you to, in HTML language mode, do things such as select HTML Menu->Lists->Unordered List, and have Alpha automatically insert a syntactically correct <UL> item as a neat little form into which you can fill elements to create the unordered list you need. In TeX mode, it lets you do things such as select TeX Menu->"Document->Insert Document ->Letter", and it inserts all the necessary control code to define a business letter, into which you only need to fill your specific content.

• OzTeX is an implementation of the TeX typesetting system as a GUI application, but more importantly, it's a viewer for the results of TeX typesetting and a front-end application that integrates a number of different tools that must be run to handle all aspects of typesetting a document using the TeX system. OzTeX currently contains an internal implementation of the TeX system because of its heritage as a Mac OS application, and additionally can use command-line TeX tools. It is expected to eventually transition to a more Unix-like application, when it will make full use of the command-line TeX tools and be relieved of the burden of the internal implementation. OzTeX is available from http://www.trevorrow.com/oztex/. Because all of TeX is community supported, many useful little packages are contributed by different authors, and it sometimes takes a while to accumulate all the useful bits that you might want for a project. On the OzTeX CD, Andrew Trevorrow distributes many useful TeX-related tools and auxiliary packages, so if you find TeX and LaTeX to be useful to your work, but find that you'd like more third-party utilities than you really want to install, Andrew's OzTeX CD is a great convenience.

• TeX, as has been previously explained, is an expert typesetting system embodied in a suite of several traditionally command-line applications. The input that you provide to TeX is a plain text document containing the content you want to typeset and, optionally, small fragments of code in the typesetting language that TeX speaks, to describe to the system any nondefault formatting that you want to apply. You mark up your content in plain text using a simple syntax to indicate the content's structure. TeX reads your marked-up text, applies either its default rules for formatting the structures you've marked up or any variant formatting you've requested, and writes out a formatted version of the document in a .dvi (device independent) file. This file can then be read by DVI viewers (such as OzTeX) to show you what the formatted output will look like, or converted into any number of printer-driver languages (such as PostScript) for delivery to a hard copy output device.

  LaTeX is a macro package that lives on top of TeX and provides a number of advanced document formatting features to the author. All major TeX implementations include the LaTeX macro package as a standard component.

  Gerben Wierda's TeX implementation is a blend of a number of TeX distribution lineages packaged as a convenient Mac OS X .dmg installer, or as a network-aware installation program that downloads and installs needed components when run. It is available from http://www.rna.nl/tex.html (and also on Andrew's OzTeX CD). The i-Installer version of the installation program is recommended.

Taken together, these packages allow the following chain of events to occur relatively seamlessly: You author TeX and LaTeX documents in AlphaX. When you're satisfied with the content (not the appearance the content what you have to say) you've created and want to see how it will look printed, you trigger AlphaX to hand off these documents to OzTeX by use of a menu selection, or a key press combination. OzTeX determines the document type and invokes TeX or the LaTeX macro package, as appropriate. TeX formats the document and writes a .dvi file. OzTeX recognizes the creation of the .dvi file and opens a viewer showing you exactly what your document will look like when printed.

This might sound like a long and cumbersome sequence of events, but by now, it should seem like a perfectly logical Unix way of proceeding. Also by now, you should be getting the idea that Unix allows the programmer to hide many of these interactions from the user, if the user wants to ignore them. From the user's perspective, it turns out that this interaction is not particularly cumbersome at all. Instead, in practice, the process looks like you type some content into an AlphaX window and press Command-T. A second or two later (faster if you have a machine with more horsepower than my G4 PowerBook), a preview of your document, exactly as it will print, appears in a window. Note that this is actually much more WYSIWYG than what you get from a normal WYSIWYG word processor. With this system, what you see is directly rendered from the code that will be used to drive your printer. If you've ever fought with the weird "What You See Is (Kind of Like, But Not Quite) What You Get" problems some word processors seem to always have with font widths not being quite right and character alignments being ever so slightly off between the display and the printout, you'll find this display to be refreshingly accurate. Being derived from the code that drives the printer, it contains all the same positioning and formatting as what will print. Your display might not have the resolution of your printer, and so might not be able to display characters exactly identically, but they should be pixel-perfect in their formatting and alignment.

Figure 13.9 shows the code of a simple LaTeX document to construct a business letter, as shown by AlphaX. If this book were in color, you'd see the syntax coloring indicating that the editor knows which parts of the document are LaTeX commands, which are comments, and which are my actual content. The entire structure of this document was set up for me by AlphaX; all I've done is filled in my textual content where I needed it and a bit of code to pull in my digital signature file. It may be of interest to note that lines starting with % symbols are comments in TeX/LaTeX. Being a programming language, I can comment out parts of the document to keep them from displaying or printing, while still keeping them unaltered in the text document itself. This can be useful when working on multiple versions of the same document or when making sweeping changes to a document where large sections need to be deleted or rearranged, but you don't want to lose track of important points made in the original.

Figure 13.9. Editing a LaTeX document in AlphaX.

Also remember, this is a plain text document. I can edit it at the command line with vi or emacs. I can typeset it at the command line using the command-line TeX tools. If I'm away from home and I need to edit it and print a copy for my secretary, my PCS-modem phone and my PDA are all I need to connect to my desktop machine, fire up a text editor, make the edits, typeset, and print a new copy. Editing the document is location and software independent, and because TeX runs on almost every hardware platform conceivable, if I want to take it with me, typesetting it is location and hardware independent as well.

Figure 13.10 shows OzTeX's view of the output from Figure 13.9's LaTeX code. If you have particularly good eyes, you'll notice that the text formatting displays the characteristics of text layout done by a typesetting professional. Character pairs such as fi show proper ligatures, and line lengths are massaged, by minute variation of intercharacter and interword spacing, to avoid widow words at the end of paragraphs. Considerably more is going on behind the scenes that isn't apparent from this partial-page display, such as paragraph balancing to avoid widow lines at the top of pages, proper formatting of oblique as well as italic typefaces, and too many more careful optimizations of the layout to name.

Figure 13.10. The result of LaTeX formatting the code shown in Figure 13.9.

NOTE

If you've found this notion of a plain-text, programmatic typesetting language to be of interest, we encourage you to check out Donald Knuth's definitive work on TeX The TeXbook and Leslie Lamport's definitive work on LaTeX, LaTeX: A Document Preparation System. Helmut Kopka's A Guide to LATEX: Document Preparation for Beginners and Advanced Users is also a good book that actually covers a fair bit of what you need to know about both LaTeX and the underlying TeX system. If you're tempted by the idea, think back to this system after you've read through Chapter 15 on shell scripting, and Chapter 18's section on Perl programming. The ability to automate changes to documents and build formatted text structures with software can be useful. The plain text nature of TeX's input lends itself nicely to such manipulation.

We don't expect the majority of our readers to decide to become TeX hackers based on this short introduction, but even if it doesn't sound interesting enough to install the software to try it out, we hope you come away from this discussion with an idea of what is possible if the power of the GUI and the command line are taken together. Even if TeX just isn't your thing, understand that what this specific-programs-for-specific-functions system allows is complete customization of a word processor environment.

Due to the newness of Mac OS X, you're currently rather limited in your choices for filling out this suite, but imagine if all word processing applications were handled in a similar fashion, instead of as monolithic applications like MS Word. If you didn't like a component, you could easily switch it out and use a different one that provided better functionality for your use in its place. In this instance, you can switch out AlphaX for BBedit or any other command-line editor. It makes no difference to the system, choose whichever one you like. If you don't like OzTeX, there are a half dozen other TeX front ends (see Weirda's list at http://www.rna.nl/tex.html for details) that can sit between your editor of choice and the TeX command-line software. If you don't like LaTeX/TeX as a typesetter, you could use PDFTeX (typesets LaTeX directly to PDF files), or one of the *roff family of text formatters (an unpleasant group of text formatters primarily used for formatting Unix man pages these days; see the man page for groff if you want the gory details), or txt2pdf (http://www.sanface.com/txt2pdf.html). If the major software vendors get on board with this way of doing things, you'll suddenly be able to pick the best components from each to meet your own personal working style and the requirements of the work you need to do.