Command-line skills confer the power to speak to the machine. Despite a decade of effort to replace the DOS or Unix command prompt with a point-and-click user interface, fluency at the command line still streamlines many operations. Its welcome news, then, that Microsofts “Longhorn” initiative includes major improvements in commanding system actions.
In the 1980s, PC users were baby-duck-imprinted with the power of batch files and their higher-level commands, using conventions adopted from Unix. Those facilities are still available in console windows. Ive even been known, in decades past, to accelerate a task by writing a batch file that composes and runs other batch files issuing complex strings of commands.
Our modern-day tool kits feature far more general scripting languages, such as REXX, Python, Ruby, REBOL and Perl; power users have also hailed the appearance of command lines and associated scripting facilities in Mac OS X.
Even so, I wonder if this sort of power-talking to PCs is a dying art on the client side of the IT tracks, despite its popularity on servers. Its a real loss—as if we gave up verbs and pronouns to return to caveman-style point-and-grunt communication. Its understandable, though, that users find the command line inadequate for working with todays rich forms of data.
What strands the traditional command line in the 20th century is its limitation to text-based input and output. The problem is forcefully summarized in Chapter 8 of “The Unix-Haters Handbook,” a 1994 compendium thats been posted by its editors at www.web.mit.edu/~simsong/www/ugh.pdf.
The books bill of particulars against Unix-style commands and their connecting pipes begins with their one-way flow of information. More seriously, it continues with the requirement that the receiving and sending processes must use a stream of bytes. “Any object more complex than a byte cannot be sent until the object is first transmuted into a string of bytes that the receiving end knows how to reassemble,” the handbook observes, adding that a process cant send an object or a pointer into another process address space or a handle to a file.
When we try to represent abstractions like these—for example, with path strings to files or with names of “helper” applications to be used—we wind up with house-of-cards solutions that may demo well but dont hold up in real life.
Its especially important to note that current command-shell technology imposes conversion to text strings at many points, not only at the beginning and end of a process. The state of play has to be represented in that limiting form at every intermediate step, saddling the user with laborious and error-prone parsing chores and discarding useful metadata. Think about how annoying it would be to have copying and pasting of unformatted text as the only possible data transfer among GUI applications, instead of being able to paste and edit tables or figures—or even more active objects.
The Longhorn vision transcends these limits with Microsofts next-generation command line—dubbed Monad, or MSH—that gives our commands a work space of .Net objects. As Jeffrey Snover, Microsoft management architect, put it: “We keep the idea of A pipe to B pipe to C, but we pass .Net objects instead of structured text. We can pass ADO, other kinds of objects, and we can create reflection-based utilities.”
The goal, Snover continued, is to let users interact with many stores of data as easily as they do with the file system today. Registry keys or networked devices, for example, can be just as accessible as files. Thats not enough, of course—accessibility alone just lets people make a mess more easily. The rest of the solution is a programming model thats far more consistent and robust in handling the errors—that is, the violated expectations—that inevitably arise in distributed environments.
The Monad bits are available now at beta.microsoft.com. I hope people dont wait to see what this looks like in the context of Longhorn (or should I call it “Longwait”?). I hope developers will think about the implications and start working now to give us comparable power in standards-based environments as well.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.