Re: [OT] AppleScript scripts versus Shell scripts
Re: [OT] AppleScript scripts versus Shell scripts
- Subject: Re: [OT] AppleScript scripts versus Shell scripts
- From: Sam Griffith <email@hidden>
- Date: Wed, 29 Jan 2003 09:16:22 -0600
Randal,
1/26/2003 7:15 PM, "Randal L. Schwartz" <email@hidden> wrote:
>
>>>>> "John" == John C Welch <email@hidden> writes:
>
>
John> On 01/26/2003 19:37, "Randal L. Schwartz" <email@hidden> wrote:
>
John> Perl is a text processor. It doesn't have to deal with the
>
John> vagaries of everything from Photoshop to FileMaker to netOctopus.
>
>>
>
>> If that's your opinion of Perl, it undermines the rest of your argument.
>
>>
>
>> I'd point you to perl.org for more info.
>
>>
>
>> Perl *is* the Glue for Unix, just like AS is the Glue for MacOS.
>
>
John> Really...care to detail the Perl dictionaries for manipulating
>
John> functions in the Unix version of FrameMaker?
>
>
None needed. There's a CLI interface to fmmaker, if I recall. And
>
co-workers of mine have written Perl programs to "script" various
>
actions of that CLI.
AppleScript provides a standard way for applications to expose there object
model via dictionaries. What you describe is Adobe having done the same
thing for Framemaker, but in Unix there isn't a standard way for
applications to describe what functions are exposed. So you may end up with
something like 'fm -e "import <datafile> <outputfile>" etc. as the exposed
dictionary. The difference is that in AppleScript those methods and objects
that an application exposes are registered in a standard way in an
application dictionary that can be queried programmatically. Unix
applications just don't have this standardized way of allowing for that to
happen. It may be documented as set of command line options and parameters,
but it is not intrinsically part of the definition of an application itself.
In the Mac OS, applications are treated as not just a set of commands with
options, but as real live instances if you will. So the application has
state and methods that operate on that state.
>
>
The beauty of it is, Perl doesn't need every program to add stuff just
>
to get it to work with Perl. Perl uses the standard Unix interfaces
>
to provide controlled input, parse the output, and manage the starting
>
and stopping of processes.
>
>
Unlike AS, which requires that *every* process cooperate somehow.
AppleScript is not really different then. Our standard interface is that you
must provide a list of events and data types that your application can
manipulate. Perl, sed, grep, awk and other Unix commands may look so easy,
because they are at the lowest common denominator of Unix, the stream. (And
that is not a bad thing) This does however not promote the idea of having
groups of applications that all operate on the same data types and have a
common command set that they can commonly use. AppleScript tries to bring up
the abstraction level to an object level. This is why "Suites" need to be
defined and standardized. So that we can operate at a higher level of
abstraction.
>
>
Please, I'm not interested in an appendage length contest here. I'm
>
just trying to draw a parallel. To the degree that AS lets a
>
poweruser script MacOS, Perl is that same tool for Unix. That's
>
all I'm saying.
I agree! They both are the power users tools. But AppleScript tries to go
farther than the standard streams and commands idea in Unix. AppleScript
tries to go to the level that HyperCard did. To take the idea that an
application should be treated as an object and be able to queried with
respect to it's command and data definitions, that it be event based and
that by providing a framework for doing so at the OS level, including basic
"Event Suites", that the level at which programmers and end users could
script would rise above the streams idea up to the object level. In affect,
make the objects doing the work the focus (what can they do for me), not the
data. The Unix streams approach tends to focus on how to manipulate the
data to get it to look like what I want.
Both have there places and I don't think one has anything over the other.
Some things need to be operated on as data and munged at that level, other
things make more sense to be treated as objects and ask them to do work for
you.
One last thing, you can think of some of that adding stuff to the
applications to get them to work with AppleScript and others, as adding
things like the man page info. Etc. It's kinda like saying "perl -h" to get
the command line options. But at a higher level, because the AppleScript
dictionary shows me all the commands and all the data types this program
knows about. The "-h" option of Unix commands doesn't usually go into that
level of detail. I've got to read the man page....
Thanks for you time....
Sam Griffith Jr.
email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.