using tell with proc. serial numb. in OS X
using tell with proc. serial numb. in OS X
- Subject: using tell with proc. serial numb. in OS X
- From: "Neal A. Crocker" <email@hidden>
- Date: Tue, 13 Nov 2001 01:04:40 -0800
(please note that I'm cross posting this message to applescript-users
and applescript-implementors. Normally, the topic matter for these
two lists is very different, but the questions in this particular
post are suited to both lists.)
Here's a question for you Applescript Engineer types who are
developing Applecript and anyone else who's good at answering unusual
questions about Applescript capabilities:
Suppose I'm writing a script which I will run in OS X from an
application such as Script Editor. Suppose my script, during the
course of its execution has a variable containing a value of class
"psn " which is a valid process serial number, corresponding to a
currently runing process that can receive appleevents. Can I use
this variable as the argument of a tell statement to send events to
the application corresponding to the process serial number? In other
words, could I create a working script with something like the form:
tell <<psn abcdefgh>> -- abcedfgh is raw data that translates to
the psn of the target application
do some event
end tell
A related question is whether I can use the tell statement in an
application to direct events to a process using its unix "process
id", or "pid". In other words, could I could I create a working
script with something like the form:
tell <<pid abcd>> -- abce is some raw data that translates to the
process id (pid) of the target application
do some event
end tell
If there'e no way to do what I'm asking, then consider it a feature
request. The reason I want this capability is that some day, some
young enterprising applescript implementor (maybe me) is going to
develop a unix command line tool that listens for appleevents. It
would be used, of course, as a command typed at the command line or
in a shell script, and more than one process might be using the tool
at the same time, as with any unix command line tool. The only way I
can see for Applescripter to write a script which can send events to
a process using such a tool to listen for events is for the script to
use the process' process id (or its process serial number translated
from its process id) as the argument of a tell statement. This is
because process running command line tools, unlike application
processes, can only be uniquely identified by their pids or psns.
All the ways that a script normally uses to identify an application
process to which to direct events won't work with command line tool
processes. Generally speaking, only one instance of an appication
can be run at a time (unless you duplicate the application file and
run the duplicate application). Thus, there will be only one
application named, for instance, "Appleworks 6" running at a time.
In contrast, a given command line tool can be running in simultaneous
in many separate processes. For instance, opening multiple terminal
windows in Terminal.app causes tcsh to run in each window. Thus,
there can be many "tcsh"'s running at one time. Thus, while an
application may be identified as the target for events in an
Applescript using its name, a command line tool process can't.
Applications have a one-to-one relationship between application file
and process. Command line tools don't. Thus, while an application
may be identified as the target for events in an Applescript using
its file, a command line tool process can't. Applications typically
have unique "signatures", such as "BOBO" for Appleworks 6. Command
line tools usually don't. Thus, while an application may be
identified as the target for events in an Applescript using its
signature, a command line tool process can't. As far as I can see,
while there are several way to identify traditional applications in a
tell statement in an Applescript, the only way to uniquely identify
which command line tool process to send appleevents to is to use its
process id or process serial number in a tell statement.
Thanks,
Neal.