Re: AppleScript and shell scripting
Re: AppleScript and shell scripting
- Subject: Re: AppleScript and shell scripting
- From: T&B <email@hidden>
- Date: Wed, 1 Aug 2007 11:45:48 +1000
Hi All,
I've actually found this thread of discussion interesting. Thanks to
all that have contributed, and for showing a fair degree of personal
respect.
Now for my own 1.7c (at current Aussie exchange rate). This may annoy
or affirm all "sides" equally ;-) Please read in full before you
comment on a snippet.
I agree that the AppleScript Users list should be reserved for
discussion about AppleScript. But I also think that AppleScript is a
unique language/environment that depends on other software for a lot
of functionality, so it's inevitable that there will be some
discussion here of those other software packages and the syntax they
use. The question then becomes "where do we draw the line?"
AppleScript provides a language/environment to tell other programs
what to do. You can use it to script AppleWorks or iWork to draw
object of a particular color, create charts etc. You can use it to
create a spreadsheet to perform complex trig calculations, by telling
spreadsheet software what to do. By design, it has a very small syntax
library within itself, and only basic maths and string functionality.
It is designed to glue or automate the functionality of other
programs, not re-invent that functionality within itself.
So picture, for instance, a page layout department like, say the LA
Times (I would imagine, but also recall seeing a great AppleScript
promo video featuring some AppleScript scripter ;-) ). There would be
existing manual workflows involving Quark XPress, the Finder, perhaps
some graphics and database software. FileMaker (or similar) would
organize the source data. XPress would already be used for
manipulating text and layout. The graphics app would handle image
manipulation. FileMaker handles records of data. The Finder handles
files and folders, etc. AppleScript would be a great tool to use here
to automate the existing features of those programs into one (or
multiple) coherent solution.
Such an AppleScript solution depends on the functionality, features
and the syntax (GUI steps or AppleScript dictionary or some other
built in scripting environment) of the software it controls. If the
author of such a script were to post questions here, I would expect to
see the question and answers overlap into discussion of what to click,
drag, type or create in those other software programs, such as
snippets of FileMaker scripts (not AppleScript), how to create
particular layouts in XPress or folders in the Finder. I'd also expect
to see AppleScript code sections specifically targeting the syntax of
the dictionaries of particular applications.
It would often even be helpful to see snippets of answers such as
"AppleScript is particularly poor at scripting that procedure in
FileMaker, so you're better off writing that whole section in
FileMaker's own scripting language, and simply calling it from
AppleScript via 'do script'." In that case, on the one hand I think it
would be helpful for the poster to include a wad of FileMaker code so
the reader can simply replicate it in their own solution, without
having to go learn that other scripting language, and instead focus on
the AppleScript syntax to call it and manipulate the result. But on
the other hand, I wouldn't like to see the thread digress into
detailed discussion of that other scripting language.
Similarly, it would likely be helpful for answers to describe how to
set up an XPress document template (via click, drag, menus etc, all
manual) to be best formatted. But again, it should be just a recipe of
steps with the aim to prepare it for AppleScript to interact with it,
aimed at someone who knows (or is learning) AppleScript, not aimed as
a tutorial in how to use XPress. Any detailed discussion of XPress
formatting etc, unrelated to AppleScript, should be taken elsewhere,
such as an XPress forum or private emails.
As I mentioned, AppleScript has very little syntax of its own. Other
languages such as C also have very little functionality of its own.
Both have very little built in string manipulation or math functions,
for example. C, of course, has a range of standard libraries to
include to obtain such features. It's rare to see all but the most
basic C program without an "include" statement at the beginning, to
include some library of extra functions. AppleScript, however, is
designed to manipulate other software, not really build a self
contained solution. So it could be argued that it doesn't make sense
for it to have a set of libraries, instead relying on the
functionality of the software it controls.
For instance, if you're scripting AppleWorks to draw objects based on
trig functions, you can use AppleWorks' spreadsheet suite to calculate
trig in spreadsheet cells. If you were scripting graphic objects in a
graphics program that lacked trig resources, you'd have to bring some
other program into your solution that did provide trig. That's great
in theory, but we quickly feel the burden of loading an entire
spreadsheet program just to run a trig function, or an entire text
processor just to perform a string substitution. It's further
complicated if we're building an AppleScript solution for deployment
on other workstations, since that would then require purchase,
installation and support of multiple copies of those extra programs.
So enters the Scripting Addition (aka OSAX). They are effectively
libraries of targeted functionality, without the GUI overhead of a
full application. A couple of Scripting Additions can save us from
having to install an entire Office suite of applications to fill the
gaps in an AppleScript solution. Compared to running a script that
uses extra applications, Scripting Additions save us from long launch
delays, visual artifacts (splash screens, documents opening and
closing), memory and disk space. They also minimize cost and
distribution/installation problems.
However, Scripting Additions aren't as portable or integrated as say a
C library. We face issues of deployment in that we have to install
them in the right place on each workstation. We often have to buy
them. But most annoyingly, I've found, is that they are often not
updated to match the technology, such as when Macs went from 68k to
PPC to Intel, and from OS9 to OSX. Even with free Scripting Additions,
there is often no source code we can use to recompile, and even then,
we have to be a C coder to know what to do or how to fix it.
BTW, OSAXen (aka Scripting Additions) serve no useful purpose without
AppleScript. They don't have their own GUI or non AppleScript syntax,
so I'd say any discussion of OSAXen is fair game on an AppleScript
list. But again, we wouldn't discuss here the C coding that makes them.
It's kind of an irony that although AppleScript is designed to
manipulate and depend on other software to build solutions, we shy
away from having to include other software in those solutions.
Personally, my reluctance is wanting to avoid the overhead of
installation, maintenance and GUI artifacts of other software. But
there are also cost and other factors. This desire to minimize or
eliminate the need for extra software in our AppleScript solutions
drives many of us to ask for "vanilla" (ie plain, without extra
flavoring) methods. This translates to one or both of these aims:
1. Includes only AppleScript code.
2. Will run on any Mac without having to install extra software.
Based on the above discussion, I think we could argue that aim 1 is
technically impossible, since the core AppleScript syntax is very
limited, and by nature requires at least an application or scripting
addition to script, each with their own syntax (albeit ideally fairly
standardized). In other words, whatever method we follow for most real
world tasks, we're going to have to use some extra syntax, beyond the
core AppleScript commands (eg set, get, repeat, tell).
Aim 2 is what I, and I think most others, are usually after. I prefer
a solution that requires the minimum additional software to be loaded.
But I also want to focus on the AppleScript code in the solution.
If I ask, for instance, "how I can do a string search", I may get an
answer such as one of the following:
1. Use the TextWrangler application, calling the following AppleScript
event in its dictionary.
2. Use the TextCommands or Satimage OSAX with the following
AppleScript event in its dictionary.
3. Since you're already using Pages/XPress in your solution for other
purposes, you can use this event from its dictionary.
4. Call the following subroutine/handler written in pure AppleScript.
5. Call the following subroutine/handler that uses do shell script to
use perl to do the work.
6. Use "do shell script" to run some perl. Here's some perl code which
you can alter to suit.
7. Forget AppleScript and do the whole thing in this other scripting
language. Here's some code.
Methods 1 and 2 above require me to use extra software, so I would
prefer to avoid them. Method 3 would be preferable in many situations
since it requires no more software than I'm already using in my
solution. But the visual overhead of watching windows open and close,
and the time overhead would often be undesirable.
I expect that method 2 (scripting additions) would offer the fastest
execution. It's probably the closest match to the paradigm of
including a C library in C code. But it doesn't satisfy criteria 2 of
"Vanilla AppleScript". Technically, it could be argued that it doesn't
satisfy criteria 1 either, since the scripting addition is written in
C which can't be altered or recompiled by an AppleScript scripter (or
most often anyone else).
Method 4 satisfies both "Vanilla AppleScript" criteria. I'd most often
prefer it if it was for a task for which AppleScript did a fair job.
But I think complex regular expression matching (for example) requires
too much code and time overhead in pure AppleScript.
Method 5 satisfies the 2nd (but not the 1st) criteria of a "Vanilla
AppleScript" solution. I would prefer this method above all others in
most cases because it:
1. Requires no additional software to be loaded.
2. Can be called from pure AppleScript. I just need to know the
parameters to feed it.
3. Has full functionality and high speed and doesn't require pages of
code to reinvent something that's already built into my computer.
Such a solution might look like this:
Hi Tom,
Here's a solution to your request for a way to do text searches from
within AppleScript. Call this handler:
GetRegexMatches of regexString into searchInString
To make this call work, just paste in the following handler into
your script:
on GetRegexMatches of regexString into searchInString
-- code would appear here, including a call to "do shell script"
return resultList
end GetRegexMatches
I think that would be a great solution. All I'd have to do is paste
their handler into my script and call it using pure AppleScript. I
don't see this as any different (in terms of AppleScript purity) to
someone posting a solution that requires me to install a scripting
addition written in C, or a scriptable application. They've kept the
focus on using AppleScript and simply provided a foreign tool to make
it work. By nature AppleScript requires such foreign tools.
Furthermore, where such a foreign component (such as my
GetRegexMatches handler) incorporates foreign code (shell and perl in
this case), I think it's fair game for us to post optimization
suggestions as alternatives to that full handler. Although the new
handler would involve new perl code, it's still wrapped in
AppleScript, so pure AppleScripters can use it. And by wrapping it in
a handler, it minimizes the "abomination" of seeing two languages mid
code. BTW, if you're interested I'll post separately a sample for the
code above that actually works, and leave it open for others to improve.
Method 6, I think, is not a good posting on this AppleScript list.
Though it uses the same technologies as method 5, it takes the focus
off editing AppleScript code, and instead focuses on editing some
foreign language (perl in this case). I think we should all endeavor
to wrap in AppleScript any solution that we post here. Then we advise
the user to call sample pure AppleScript code to invoke it.
Method 7, I think, does not belong on this discussion list. However,
sometimes when someone asks how to use AppleScript to do something it
just isn't good at, such as how to write a 3D game in AppleScript. It
would be a good idea to direct them to environments suited to their
purpose, without carrying on a discussion here about foreign syntax.
Similarly, I think that questions posted that have nothing to do with
AppleScript, or which are more focussed on the syntax of a foreign
language (or the GUI of a "foreign" application), do not belong on
this discussion list. For example, someone posted a query recently
about shell scripts at start up, which I don't think belongs here. And
I have a question about a backup script, using shell's "ditto" and I
need to know how to find out if a disk is mounted from shell etc, but
that doesn't belong here. Detailed discussions of FileMaker scripts
(not AppleScript) or page layout methods in XPress do not belong here.
The MacScrpt list is one of several options for such questions (eg for
Mac shell scripting), and FileMaker lists for FileMaker etc. If an
alternative forum isn't used much, that doesn't warrant extra noise on
this list, as interesting as it might be.
I hope this unifies some thought,
Thanks,
Tom
_______________________________________________
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