Re: AppleScript and shell scripting
Re: AppleScript and shell scripting
- Subject: Re: AppleScript and shell scripting
- From: "Mark J. Reed" <email@hidden>
- Date: Mon, 30 Jul 2007 02:55:15 -0400
On 7/29/07,
John C. Welch <
email@hidden> wrote:
One thing I will say that seems to have been ignored is the importance of a
good environment. While you have advanced IDEs for many languages, including
AppleScript, shell is still stuck back in the realm of stone tablets and
pterodactyls. Perhaps if there was an environment on the level of Script
Debugger for shell, it would become a lot easier. I know that if I ever get
serious about Perl, I'll be writing another check to Mark for Affrus.
The shell is not a programming language. At least, not primarily. If you're doing application development using the shell as your implementation language, you've got a lot more problems than the tool set. :) It can be done, surely - the appendix to the KornShell book is an implementation of the MH email client using nothing but ksh - but that was more of a demonstration of the shell's power than a recommendation for future application development.
The shell is, fundamentally, a program that lets the user execute other programs. It's the CLI equivalent of the Finder; a command like "awk '{hey}' file1 | sed 'there' >file2" is tantamount to double-clicking Awk, hitting File->Open, selecting "file1", using Awk-specific menus to perform the logic represented by 'hey', copying the result to the clipboard, double-clicking Sed, pasting the result in, using Sed-specific menus to perform the logic represented by 'there', and hitting File->Save and typing in "file2". (More or less; technically, the shell is responsible for saving to file2 in the example.)
Normally, in a CLI environment, you type out commands interactively and see the results on your screen before typing the next command. A shell script is a place where you can store the commands for later execution, and wrap them with loops or if statements or whatever to make the automation more flexible. Basically, the fact that most shells have all that programming-language
goodness is the CLI equivalent of the fact that the Finder
is scriptable. That's probably the best way to think about the term "shell
script(ing)": you are scripting the shell.
But since the shell dates back to stone tablets and pterodactyls, it's not part of some structured system-wide scripting API. The system-wide scripting API was called "strings", as in "you can pass strings to programs and get strings back out of them". At least in the UNIX world(*) there's no automatic way to discern what arguments the various programs expect. So in order to develop a full-fledged IDE for the shelll, you'd essentially have to develop a full-fledged IDE for every program in $PATH.
So, effectively, the shell is its own IDE. You can type commands interactively and see the results immediately. Modern shells even have completion on the names of commands and files, and you can set up some (like tcsh) to do completion on non-filename arguments to other programs as well. If that's not enough of an IDE for the task at hand, then the task at hand is probably best accomplished with something other than the shell.
(*) Other CLI environments did have this sort of functionality; here I'm thinking of CDC NOS/VE, where the mechanism for execution from the shell meant that every program so executable had an execution template with strongly-typed arguments, accessible interactively via the "display_command_information" command. Handy, but not typical, probably because it was probably more trouble than it was worth for the application developer.
--
Mark J. Reed <
email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden