Re: using tell with proc. serial numb. in OS X
Re: using tell with proc. serial numb. in OS X
- Subject: Re: using tell with proc. serial numb. in OS X
- From: "Neal A. Crocker" <email@hidden>
- Date: Wed, 14 Nov 2001 02:18:52 -0800
On Tuesday, November 13, 2001, at 01:04 AM, Neal A. Crocker wrote:
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?
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".
...command line tools, unlike application processes, can only be
uniquely identified by their pids or psns.
The Apple Event Manager supports both psn and pid addresses in Mac OS X 10.1.
Out of curiosity, how does the Apple Event Manager support pid
addresses? From the documentation, as far as I can tell, there's a
way to translate pids to psns (in Processes.h) and addresses can be
made from psns but not pids. Its possible I missed something. I had
to do some severe digging before I came across any indication in the
documentation that pids could be translated to psns. The knowledge
that pid can be used as addresses could be equally deeply buried.
If you're sending events from C, it's no problem. We haven't
exposed them in AppleScript yet, partly because we'd need a sensible
way to get one in the first place.
Your observations about unique identification are well taken, but I
think you're still missing the point: if you've got ten different
invocations of, say, widgetd running, how are you going to tell
which one you want to talk to?
Either there is a way, so the pid isn't the only means of
identification, or there isn't, in which case you're either screwed
or you just don't care and pick one at random.
Identifying which of the process running "widgetd" to send to would
depend on the purpose for which events were being sent and which
script was sending them. Presumably each "widgetd" process listening
for appleevents was started by some parent process that had some use
for it. The parent process would have access to its pid. This
suggests at least one possible use for directing events by pid. A
shell script could conceivably launch one or more background process
that listens for appleevents that would provide services for it.
Pids would make a very useful way for the parent process to direct
events using the osascript command to any of its listening children
if directing appleevents by way of pid were possible within
applescript. Its also conceivable that, if someone were to develop
an appropriate scripting addition (perhaps me), scripts that were
running could create child processes of their own process that ran
effectively in-parallel and provided services to them. If
applescripts could target events by pid, the pid of the child process
would be the ideal thing for the scripting addition to return when
used to create one.
Yet another use for targeting events using pids in applescript occurs
to me. Someone could conceivably develop an application that
provides a service that involves creating one or more child processes
for each client, where each child process could be communicated with
via appleevents. The perfect example could be Terminal.app if its
developers choose to do a little more work. Suppose Terminal.app
returned a pid when sent the "do script" event by an applescript.
Suppose further that the process in which the argument of the do
script is executed were to persist, as one would expect for instance
if a shell were launched. Terminal.app could support an appleevent
that would send text to the standard input of that process with the
reply event returning the contents of standard output. The event
sending text to standard input could be targeted using the pid
returned by the do script event. This would *greatly* enhance the
usefulness of Terminal.app as service provider for Applescripts,
since, as it stands, Terminal.app can only be used to "launch and
forget" shell scripts. Terminal.app currently provides no way to
communicate with the shell scripts started by the do script event.
This idea could, in principle, also be used with a scripting
addition. A scripting addition could be developed to create a
background child process that runs a shell script. It could return a
pid that could be used to target events to the child process carrying
text for standard input with the reply events returning standard
output.
Now, if we made *all* processes (not just ones with PSNs) visible
through the "processes" property, then there might be a way to
interrogate the list and find out (somehow) that, yes, this copy of
widgetd is the one you want. Internally, AppleScript would hold
widgetd's "address" as a pid, but as a scripter you wouldn't need to
be aware of that. There are some interesting technical issues with
doing this, but hey, we're already considering this an enhancement
request, so that's ok. :-)
If one could interrogate Process Viewer or some other application for
a list of all processes, it would be useful if it exposed all sort of
useful properties beyond pid, such as, for instance, the info Process
Viewer exposes in human readable form. In other words, it would be
useful if the app exposed the parent pid, the command that created
the process, the user who owns it, etc. All of this info could be
used to distinguish which process to target.
--Chris Nebel
AppleScript Engineering
Thanks,
Neal.