How do you execute an OS X application (bundle) from Python?

[David Hughes]

For example, in Python in a Nutshell, Alex Martelli shows how you can
run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
os.spawnv(os.P_WAIT, editor, [textfile])
But how would you call the OS X text editor /Applications/TextEdit.app
- which appears to be a whole directory inside /Applications?

I'm sorry if the answer is blindingly obvious. I work alone and
sometimes just get stuck, then have to ask in public and risk
appearing a noodle brain.

David

[Piet van Oostrum]

>>>>> df*@forestfield.co.uk (David Hughes) (DH) wrote:

DH> For example, in Python in a Nutshell, Alex Martelli shows how you can
DH> run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
DH> os.spawnv(os.P_WAIT, editor, [textfile])
DH> But how would you call the OS X text editor /Applications/TextEdit.app
DH> - which appears to be a whole directory inside /Applications?

DH> I'm sorry if the answer is blindingly obvious. I work alone and
DH> sometimes just get stuck, then have to ask in public and risk
DH> appearing a noodle brain.

os.system("open -a TextEdit test.txt")
or
os.system("/Applications/TextEdit.app/Contents/MacOS/TextEdit test.text")

I suppose you can translate this also to spawn calls.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.***********@hccnet.nl

[Alex Martelli]

David Hughes <df*@forestfield.co.uk> wrote:

For example, in Python in a Nutshell, Alex Martelli shows how you can
run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
os.spawnv(os.P_WAIT, editor, [textfile])
But how would you call the OS X text editor /Applications/TextEdit.app
- which appears to be a whole directory inside /Applications?

I'm sorry if the answer is blindingly obvious. I work alone and
sometimes just get stuck, then have to ask in public and risk
appearing a noodle brain.

You could spawn the 'open' command (/usr/bin/open) which you also use to
open all kinds of files from OSX's Terminal. Unfortunately, the P_WAIT
doesn't work in the intended way in this case -- it doesn't wait for the
application to be closed (so that the user has finished editing the
file), but rather it gives you control at once.

Unfortunately, I don't know how to get the P_WAIT functionality on OSX
for a .app directory/bundle -- you may want to ask on the pythonmac-sig!
Alex

[has]

df*@forestfield.co.uk (David Hughes) wrote in message news:<70*************************@posting.google.c om>...

For example, in Python in a Nutshell, Alex Martelli shows how you can
run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
os.spawnv(os.P_WAIT, editor, [textfile])
But how would you call the OS X text editor /Applications/TextEdit.app
- which appears to be a whole directory inside /Applications?

Using os.system to execute open is pretty simple, as other folks have
pointed out. The other way is to use Apple events, the standard
high-level IPC system used by Mac GUI apps. The AE support currently
in the standard library leaves something to be desired and is due for
replacement. Much improved, though unfinished, AE support is available
from my site:

http://freespace.virgin.net/hamish.s...appscript.html

Fastest way to open a document is via the lower-level aem package
(lower overheads, though you have to use raw AE codes):

from aem.send import Application
from Carbon.File import FSSpec
Application('/Applications/TextEdit.app').event('aevt', 'odoc',
{'----':FSSpec(pathToFile)}).send()
Alternatively, the high-level appscript package wraps all this stuff
in OO-like syntactic sugar and human-readable terminology (takes
longer to initialise as it has to retrieve and parse the application
terminology):

from appscript import *
app('TextEdit.app').open(FSSpec(pathToFile))
HTH

[Alex Martelli]

has <ha*******@virgin.net> wrote:

df*@forestfield.co.uk (David Hughes) wrote in message news:<70*************************@posting.google.c om>...

For example, in Python in a Nutshell, Alex Martelli shows how you can
run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
os.spawnv(os.P_WAIT, editor, [textfile])
But how would you call the OS X text editor /Applications/TextEdit.app
- which appears to be a whole directory inside /Applications?

Using os.system to execute open is pretty simple, as other folks have
pointed out.

....but doesn't do the P_WAIT: just like using open at the Terminal
prompt, it immediately continues with your code even as TextEdit is
starting up. The idea of that snippet is to let the user edit a
textfile for configuration, while until the user is done editing, then
read the textfile etc etc. And it works file on the Mac with vi too.

But apparently the P_WAIT is not implemented in the Mac version of
Python like on the Windows version -- to *WAIT* until the app is done
before continuing. So, it looks as if one will have to put in more
complicated code in that case:-(.

replacement. Much improved, though unfinished, AE support is available
from my site:

http://freespace.virgin.net/hamish.s...appscript.html ... from appscript import *
app('TextEdit.app').open(FSSpec(pathToFile))

OK, but how does one handle the *waiting*, so as to proceed only when
TextEdit is done editing that document?

"Spawning an external editor and waiting until the user is done using it
before proceeding" is an important architectural pattern (well examined
and analyzed in Raymond's "Art of Unix Programming", like many others).

Ideally it should be the external editor of choice for the user;
foisting vi on poor innocent machistas just because it's easy to wait
for THAT and hard to wait for TextEdit would seem mean;-)...
Alex

[Dan Sommers]

On Fri, 5 Nov 2004 08:41:31 +0100,
al*****@yahoo.com (Alex Martelli) wrote:

has <ha*******@virgin.net> wrote:

replacement. Much improved, though unfinished, AE support is available
from my site:

http://freespace.virgin.net/hamish.s...appscript.html

...

from appscript import *
app('TextEdit.app').open(FSSpec(pathToFile))

OK, but how does one handle the *waiting*, so as to proceed only when
TextEdit is done editing that document? "Spawning an external editor and waiting until the user is done using it
before proceeding" is an important architectural pattern (well examined
and analyzed in Raymond's "Art of Unix Programming", like many others).
Tty based Unix programs, yes; modern GUIs, no. The usual parent-child
relationship between application and editor is nowhere to be found these
days. Consider this scenario:

1. The application requests that Mac OS launch TextEdit and that
TextEdit edit the given file.

TextEdit starts (or maybe TextEdit was already running) and
opens the document (or maybe the document was already open).
The appliction neither knows nor cares about either of those
details.

2. In any event (pun intended), the user edits the file, and maybe
even saves it once or twice just in case there's a crash, and
ponders the configuration before committing to it.

3. The user is distracted by, for example, Software Update (which
is very annoying, but it happens), and attends to that matter.
It could be a printer failure, or new email, or anything that
causes the user to start working in another application.

4. While Software Update is thrashing, the user remembers that the
configuration file is open but has already been saved, and
closes it by clicking on its window's dimmed close button.
TextEdit processes the event and closes the window without
further ado.

At which point does the application know that the user is finished
editing the file?

With vi-as-a-child-of-the-application, even if the user spawns a
subshell (and, for that matter, an entire nested X server/session), the
termination of vi is still a well-defined.
Ideally it should be the external editor of choice for the user;
foisting vi on poor innocent machistas just because it's easy to wait
for THAT and hard to wait for TextEdit would seem mean;-)...

Speaking as a long time Unix hacker *and* long time Mac user, Forcing
machistas to use a text editor instead of a GUI to edit config files
would seem mean. ;-)

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.

[Alex Martelli]

Dan Sommers <[e-mail]> wrote:
...

"Spawning an external editor and waiting until the user is done using it
before proceeding" is an important architectural pattern (well examined
and analyzed in Raymond's "Art of Unix Programming", like many others).
Tty based Unix programs, yes; modern GUIs, no. The usual parent-child
relationship between application and editor is nowhere to be found these
days. Consider this scenario:

And yet, as a user, I vastly prefer those apps which, even if they have
their own GUIs, still let me edit stuff with my text-editor of choice,
say GVIM or Emacs, even when that editor, too, is a "modern GUI" app.
Yes, the process relationship may be murkier and therefore it can be
harder for the driving app to find out when the user is done editing
that file -- nevertheless, I can be SO much more productive with my
editor of choice than with whatever the driving app may choose to use
for text editing, that, as a user, I still consider that important.
1. The application requests that Mac OS launch TextEdit and that
TextEdit edit the given file.

TextEdit starts (or maybe TextEdit was already running) and
opens the document (or maybe the document was already open).
The appliction neither knows nor cares about either of those
details.

2. In any event (pun intended), the user edits the file, and maybe
even saves it once or twice just in case there's a crash, and
ponders the configuration before committing to it.

3. The user is distracted by, for example, Software Update (which
is very annoying, but it happens), and attends to that matter.
It could be a printer failure, or new email, or anything that
causes the user to start working in another application.

4. While Software Update is thrashing, the user remembers that the
configuration file is open but has already been saved, and
closes it by clicking on its window's dimmed close button.
TextEdit processes the event and closes the window without
further ado.

At which point does the application know that the user is finished
editing the file?
The application should somehow be notified after point (4); any earlier
time would be inappropriate.
With vi-as-a-child-of-the-application, even if the user spawns a
subshell (and, for that matter, an entire nested X server/session), the
termination of vi is still a well-defined.

As is the closing of a document by an app. Whether another app has an
easy time or a hard time finding out is another issue, connected with
how well designed is the OS/desktop manager/window manager/... that is
responsible for coordinating communication between the apps.

Ideally it should be the external editor of choice for the user;
foisting vi on poor innocent machistas just because it's easy to wait
for THAT and hard to wait for TextEdit would seem mean;-)...

Speaking as a long time Unix hacker *and* long time Mac user, Forcing
machistas to use a text editor instead of a GUI to edit config files
would seem mean. ;-)

Speaking as a long time Unix lover who's reasonably recently falled in
love with the Mac, just like _many_ others these days, *because* MacOSX
*is* now a Unix -- I'd rather keep the option of editing textfiles with
a text editor, not be forced to use somebody else's idea of how that
particular file should be edited, thankyouverymuch. It's exactly the
concept that I _couldn't_ work the way I liked, with a commandline and
text editors, that kept my interest in the Mac hovering around 0 for
about 19 years. Then, suddenly, I found out that it had become an
excellent BSD *plus* a neat GUI layer -- now, *that* was interesting!

Developers of Mac apps, mostly -- and therefore developers of
infrastructure that runs on Macs to help apps -- apparently haven't yet
caught on to this reasonably-new bunch of users, me included, who see
MacOSX as just what it IS today -- a BSD with a neat GUI on top (and a
Mach underneath, sure, but that's hardly ever relevant;-). Fine, I
guess we'll stick with fink and darwinports and the like. But (unless
I'm being paid for it) I'm not going to write an application that I
would never want to use myself. So, if the only way to shell out to an
editor is to write commandline apps instead of GUIs, and use /usr/bin/vi
(which IS, after all, one editor Apple that is bundling, to which we can
easily shell out), then that's going to be what we do -- until and
unless shelling out to TextEdit or BBEdit or whatever is just as easy.

Sure, Windows and Linux DEs make it easier because they do preserve the
traditional process relationship -- I can start another process running
(whatever program, GUI or not) and wait for that process to terminate,
rather than having to reuse an existing process that already happens to
be running that program. But, since the event I need is "done
processing that specific file", I should be able to wait for that, just
as easily as I can wait for process termination.
Alex

[Dan Sommers]

On Fri, 5 Nov 2004 13:35:31 +0100,
al*****@yahoo.com (Alex Martelli) wrote:

Dan Sommers <[e-mail]> wrote:
...

> "Spawning an external editor and waiting until the user is done using it
> before proceeding" is an important architectural pattern (well examined
> and analyzed in Raymond's "Art of Unix Programming", like many others).
Tty based Unix programs, yes; modern GUIs, no. The usual parent-child
relationship between application and editor is nowhere to be found these
days. Consider this scenario: And yet, as a user, I vastly prefer those apps which, even if they have
their own GUIs, still let me edit stuff with my text-editor of choice,
say GVIM or Emacs, even when that editor, too, is a "modern GUI" app.
Yes, the process relationship may be murkier and therefore it can be
harder for the driving app to find out when the user is done editing
that file -- nevertheless, I can be SO much more productive with my
editor of choice than with whatever the driving app may choose to use
for text editing, that, as a user, I still consider that important.
Agreed. My editor of choice these days is emacsclient.

[ typical multiple-user-GUI-application interaction scenario snipped ]

4. While Software Update is thrashing, the user remembers that the
configuration file is open but has already been saved, and closes it
by clicking on its window's dimmed close button. TextEdit processes
the event and closes the window without further ado.

At which point does the application know that the user is finished
editing the file?

The application should somehow be notified after point (4); any
earlier time would be inappropriate.
Well, yes, but does TextEdit and/or Mac OS provide that functionality?
Does KDE or GNOME? Those are honest questions; I haven't written a
native Mac application since OS9, and I've never written a KDE- or
GNOME- aware application.

> Ideally it should be the external editor of choice for the user;
> foisting vi on poor innocent machistas just because it's easy to wait
> for THAT and hard to wait for TextEdit would seem mean;-)...

Speaking as a long time Unix hacker *and* long time Mac user, Forcing
machistas to use a text editor instead of a GUI to edit config files
would seem mean. ;-)

Speaking as a long time Unix lover who's reasonably recently falled in
love with the Mac, just like _many_ others these days, *because*
MacOSX *is* now a Unix -- I'd rather keep the option of editing
textfiles with a text editor, not be forced to use somebody else's
idea of how that particular file should be edited, thankyouverymuch
...
Let me try it this way: Is a "text file" (or a "sequence of bytes or
characters"), edited by hand with a text editor, the best interface to
configuration information? I must admit that I'm impressed by the
amount of point-and-click configuration I can do with KDE; I never have
to look at a config *file* unless I want to (but I can look at them if
there's a problem, which seems to be the best of both worlds).

Yes, some configurations are complex, and I *detest* the number of mouse
clicks required by some of the associated interfaces (I'd much rather
type [part of] the name of a directory than "navigate" a bunch of little
disclosure triangles up and down the file system). But I now believe
that it's only a matter of time before we discover the right GUI
paradigms to edit even these sorts of things (although I never used to
think this way).
Developers of Mac apps, mostly -- and therefore developers of
infrastructure that runs on Macs to help apps -- apparently haven't
yet caught on to this reasonably-new bunch of users, me included, who
see MacOSX as just what it IS today -- a BSD with a neat GUI on top
(and a Mach underneath, sure, but that's hardly ever relevant;-).
Fine, I guess we'll stick with fink and darwinports and the like. But
(unless I'm being paid for it) I'm not going to write an application
that I would never want to use myself. So, if the only way to shell
out to an editor is to write commandline apps instead of GUIs, and use
/usr/bin/vi (which IS, after all, one editor Apple that is bundling,
to which we can easily shell out), then that's going to be what we do
-- until and unless shelling out to TextEdit or BBEdit or whatever is
just as easy.
There's a command line BBEdit wrapper somewhere; Bare Bones would seem a
likely candidate to provide the second half of shelling out to them
(i.e., letting the parent app know when the user closes the file's
window in BBEdit).
Alex

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.

[Just]

In article
<m2************@unique.fully.qualified.domain.name .yeah.right>,
Dan Sommers <[e-mail]> wrote:

Developers of Mac apps, mostly -- and therefore developers of
infrastructure that runs on Macs to help apps -- apparently haven't
yet caught on to this reasonably-new bunch of users, me included, who
see MacOSX as just what it IS today -- a BSD with a neat GUI on top
(and a Mach underneath, sure, but that's hardly ever relevant;-).
Fine, I guess we'll stick with fink and darwinports and the like. But
(unless I'm being paid for it) I'm not going to write an application
that I would never want to use myself. So, if the only way to shell
out to an editor is to write commandline apps instead of GUIs, and use
/usr/bin/vi (which IS, after all, one editor Apple that is bundling,
to which we can easily shell out), then that's going to be what we do
-- until and unless shelling out to TextEdit or BBEdit or whatever is
just as easy.

There's a command line BBEdit wrapper somewhere; Bare Bones would seem a
likely candidate to provide the second half of shelling out to them
(i.e., letting the parent app know when the user closes the file's
window in BBEdit).

BBEdit does indeed come with a command line tool (you need to install it
separately). From the bbedit man page:

-w Wait until the file is closed in BBEdit. Normally,
the bbedit tool exits immediately after the file
arguments are opened in BBEdit. The -w option
allows the bbedit tool to be used as an external
editor for Unix tools that use the EDITOR global
environment variable. To make this work using tcsh,
add the following line to your .cshrc file:

setenv EDITOR "bbedit -w"

Just

[Alex Martelli]

Just <ju**@xs4all.nl> wrote:
...

BBEdit does indeed come with a command line tool (you need to install it
separately). From the bbedit man page:

-w Wait until the file is closed in BBEdit. Normally,
the bbedit tool exits immediately after the file
arguments are opened in BBEdit. The -w option
allows the bbedit tool to be used as an external
editor for Unix tools that use the EDITOR global
environment variable. To make this work using tcsh,
add the following line to your .cshrc file:

setenv EDITOR "bbedit -w"

Nice!!! OK, so what we need are similar commandline tools for other
useful apps, since MacOSX's own 'open' does not provide such a -w switch
(maybe it's too generic a tool for such a switch to be conceivable...?)
Alex

[Alex Martelli]

Dan Sommers <[e-mail]> wrote:
...

that file -- nevertheless, I can be SO much more productive with my
editor of choice than with whatever the driving app may choose to use
for text editing, that, as a user, I still consider that important.
Agreed. My editor of choice these days is emacsclient.

The application should somehow be notified after point (4); any
earlier time would be inappropriate.

Well, yes, but does TextEdit and/or Mac OS provide that functionality?
Does KDE or GNOME? Those are honest questions; I haven't written a
native Mac application since OS9, and I've never written a KDE- or
GNOME- aware application.

Me neither; I do expect that such notification is provided by any decent
(implies scriptable) app, but quite possibly in non-uniform ways across
apps; which means that the approach Just mentioned as being BBedit's
strikes me as preferable for such tasks. emacsclient defaults to
waiting, though it does provide a -n switch for _not_ waiting...
Let me try it this way: Is a "text file" (or a "sequence of bytes or
characters"), edited by hand with a text editor, the best interface to
configuration information? I must admit that I'm impressed by the
amount of point-and-click configuration I can do with KDE; I never have
to look at a config *file* unless I want to (but I can look at them if
there's a problem, which seems to be the best of both worlds).
My preference is generally to edit text-files by hand; I do appreciate
tools that offer some shortcuts for simple and frequent tasks (though I
have my own editor macros/scripts, of course, so "by hand" may be a very
short task anyway), but I do NOT appreciate tools that remove that
option from me, either by keeping their configuration data in
non-textual form or by not integrating in their architecture the
possibility that the user will want to edit those data.

But it's not just about configuration. Much as I like tools such as
Mail.App or MacSOUP, I resent _having_ to use their editors rather than
my favourite editor; and Command-A, Command-C, open editor, Command-V
(to start editing in my favourite editor the text that begins life in
the editor integrated in such apps), and viceversa when I'm done (plus
the closing of the editor), is about (at least) half a dozen more
shortcut keystrokes than I should need for such a common task. Any app
that at some point makes me edit text, be it configuration stuff, an
email, a post, a memo to myself (e.g. in iCal), whatever, _should_ offer
a simple shortcut to let me delegate the editing to my favourite tool
for the purpose, in my opinion.

Yes, some configurations are complex, and I *detest* the number of mouse
clicks required by some of the associated interfaces (I'd much rather
type [part of] the name of a directory than "navigate" a bunch of little
disclosure triangles up and down the file system). But I now believe
that it's only a matter of time before we discover the right GUI
paradigms to edit even these sorts of things (although I never used to
think this way).

I disagree on the assumption that "the right GUI paradigms" will be
right for *me* after over a quarter century of exposure to Unix (by
_choice_, please note -- even when professional need had me working on
VM/SP, VMS, MVS, DOS, Windows, whatever, and become an expert on the
various systems in question, Unix is always what I pined for, and kept
coming back to whenever I could -- I must obviously be warped that way).
Alex

[Doug Schwarz]

In article <1g***************************@yahoo.com>,
al*****@yahoo.com (Alex Martelli) wrote:

[snip]

easily shell out), then that's going to be what we do -- until and
unless shelling out to TextEdit or BBEdit or whatever is just as easy.

You can start-up TextEdit, edit myfile.txt and wait until TextEdit quits
with

import subprocess
app = "/Applications/TextEdit.app/Contents/MacOS/TextEdit"
file = "myfile.txt"
return_code = subprocess.call( [app, file] )

I don't know if there's a way to detect when the file is simply closed.

The subprocess module is available from

http://www.lysator.liu.se/~astrand/popen5/
I also tried

import os
app = "/Applications/TextEdit.app/Contents/MacOS/TextEdit"
file = "myfile.txt"
return_code = os.spawnlp(os.P_WAIT, app, "TextEdit", file)

but TextEdit never started up. Instead I got this error message:

2004-11-05 10:32:34.586 TextEdit[9789] No Info.plist file in application
bundle or no NSPrincipalClass in the Info.plist file, exiting
Doug

--
Doug Schwarz
dmschwarz&urgrad,rochester,edu
Make obvious changes to get real email address.

[Aslak Raanes]

Alex Martelli <al*****@yahoo.com> wrote:

Nice!!! OK, so what we need are similar commandline tools for other
useful apps, since MacOSX's own 'open' does not provide such a -w switch
(maybe it's too generic a tool for such a switch to be conceivable...?)

One might use the external editor protocol for this:

http://www.barebones.com/support/develop/odbsuite.shtml
http://www.merzwaren.com/external_editor.html

Several text editors support this protocol.
--
Vennlig hilsen
Aslak Raanes

[David Hughes]

al*****@yahoo.com (Alex Martelli) wrote

has <ha*******@virgin.net> wrote:

For example, in Python in a Nutshell, Alex Martelli shows how you can
run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
os.spawnv(os.P_WAIT, editor, [textfile])
But how would you call the OS X text editor /Applications/TextEdit.app
- which appears to be a whole directory inside /Applications?

Using os.system to execute open is pretty simple, as other folks have
pointed out.

...but doesn't do the P_WAIT: just like using open at the Terminal
prompt, it immediately continues with your code even as TextEdit is
starting up. The idea of that snippet is to let the user edit a
textfile for configuration, while until the user is done editing, then
read the textfile etc etc. And it works file on the Mac with vi too.

But apparently the P_WAIT is not implemented in the Mac version of
Python like on the Windows version -- to *WAIT* until the app is done
before continuing. So, it looks as if one will have to put in more
complicated code in that case:-(.

I don't know if that will be possible. The reason for my original
query was that I want to fire up an independent help viewer from an
application - both of which will be bundle-built. In fact, I *don't*
want to implement a wait, but I do want to use Popen from the
subprocess module to launch the viewer - so that I can use its poll()
method to check if it is already running should another launch be
requested, and also kill it on exit from the main application. But,
unlike Windows, poll() always returns a completion code of zero,
instead of None, even though the process is still running.

David

[Just]

In article <1g****************************@yahoo.com>,
al*****@yahoo.com (Alex Martelli) wrote:

But it's not just about configuration. Much as I like tools such as
Mail.App or MacSOUP, I resent _having_ to use their editors rather than
my favourite editor; and Command-A, Command-C, open editor, Command-V
(to start editing in my favourite editor the text that begins life in
the editor integrated in such apps), and viceversa when I'm done (plus
the closing of the editor), is about (at least) half a dozen more
shortcut keystrokes than I should need for such a common task. Any app
that at some point makes me edit text, be it configuration stuff, an
email, a post, a memo to myself (e.g. in iCal), whatever, _should_ offer
a simple shortcut to let me delegate the editing to my favourite tool
for the purpose, in my opinion.

Not quite what you ask for, but you may also be interested to learn you
can customize OSX text editor key bindings globally:

http://www.lorax.com/FreeStuff/TextExtras.html
http://www.deepsky.com/~misaka/MacOSX/KeyBindings.html

I think this is only for Cocoa apps (such as TextEdit.app and Mail.app).

Just

[Cameron Laird]

In article <69**************************@posting.google.com >,
has <ha*******@virgin.net> wrote:

df*@forestfield.co.uk (David Hughes) wrote in message
news:<70*************************@posting.google. com>...

For example, in Python in a Nutshell, Alex Martelli shows how you can
run a Windows (notepad.exe) or Unix-like (/bin/vim) text editor using
os.spawnv(os.P_WAIT, editor, [textfile])
But how would you call the OS X text editor /Applications/TextEdit.app
- which appears to be a whole directory inside /Applications?

Using os.system to execute open is pretty simple, as other folks have
pointed out. The other way is to use Apple events, the standard
high-level IPC system used by Mac GUI apps. The AE support currently
in the standard library leaves something to be desired and is due for
replacement. Much improved, though unfinished, AE support is available
from my site:

http://freespace.virgin.net/hamish.s...appscript.html

Fastest way to open a document is via the lower-level aem package
(lower overheads, though you have to use raw AE codes):

from aem.send import Application
from Carbon.File import FSSpec
Application('/Applications/TextEdit.app').event('aevt', 'odoc',
{'----':FSSpec(pathToFile)}).send()
Alternatively, the high-level appscript package wraps all this stuff
in OO-like syntactic sugar and human-readable terminology (takes
longer to initialise as it has to retrieve and parse the application
terminology):

from appscript import *
app('TextEdit.app').open(FSSpec(pathToFile))

[has]

al*****@yahoo.com (Alex Martelli) wrote in message news:<1gmrrsj.7ljqd6f3sgkfN%al*****@yahoo.com>...

Using os.system to execute open is pretty simple, as other folks have
pointed out.

...but doesn't do the P_WAIT: just like using open at the Terminal
prompt, it immediately continues with your code even as TextEdit is
starting up. The idea of that snippet is to let the user edit a
textfile for configuration, while until the user is done editing, then
read the textfile etc etc. And it works file on the Mac with vi too.

Ah right, I've got you now. I think you've got a problem in that
case... while the Mac OS is partly Unix that's not the same thing as
actually being Unix (or Windows); what's good for one may not be for
the other. For example, the following seems to work:

os.system('/Applications/TextEdit.app/Contents/MacOS/TextEdit
/Users/has/ReadMe.txt')

However:

1. I've no idea if this sort of thing is formally supported by Apple.

2. It launches a new TextEdit process even if one already exists; a
very unMac-like thing to do. Multiple documents should open under the
same process, and even if the OS doesn't enforce it your users
certainly won't like you doing anything else.

3. It doesn't return until the process quits. Simply closing the text
document - which is when you want it to proceed - won't quit the
process (nor should it, since this is not how Mac applications
operate). This will annoy users even more.
Personally I don't have a huge problem with the Mac's indifference to
this stuff: Mac Is Not Unix after all, and has always had its own ways
of doing things. The upper levels in particular (i.e. where the GUI
apps live) are firmly in the event-driven camp. The bit that ticks me
is that Apple go to all the trouble of creating this big, clever
event-driven environment, but don't think to add a decent system for
third-parties to request and receive notification events when
something of interest occurs elsewhere.

What you really want it to tell TextEdit to open a document in a new
window AND ask that it send you a notification event when that window
is closed. Right now, the only way to do that would be via a
third-party utility that lets you attach scripts to the application's
GUI objects and listen for messages that the app sends to those, but
that's hardly the ideal solution.
Under these circumstances, the usual solution is to poll TextEdit via
its Apple event interface to detect when the document window is no
longer open. It's a bit tedious and rather unelegant, and only viable
for applications that have adequate Apple event interfaces, but in
this case it ought to do the job without any problem, e.g.:

#!/usr/local/bin/pythonw

from appscript import *
from Carbon.File import FSSpec
from time import sleep

te = app('TextEdit.app')
se = app('System Events.app')
path = '/Users/has/ReadMe.txt'

te.open(FSSpec(path))
while (se.application_processes.filter(its.name == 'TextEdit').count()
and te.documents.filter(its.path == path).count()):
sleep(1)
HTH

[has]

df*@forestfield.co.uk (David Hughes) wrote in message news:<70**************************@posting.google. com>...

I don't know if that will be possible. The reason for my original
query was that I want to fire up an independent help viewer from an
application - both of which will be bundle-built. In fact, I *don't*
want to implement a wait, but I do want to use Popen from the
subprocess module to launch the viewer - so that I can use its poll()
method to check if it is already running should another launch be
requested, and also kill it on exit from the main application. But,
unlike Windows, poll() always returns a completion code of zero,
instead of None, even though the process is still running.

Dunno if the os module is any use for process management at the GUI
level. (The docs don't indicate Mac compatibility, but I'm not sure if
they've been revised since OS9 days. You'd need to ask Jack Jansen
about this.) Anyway, I can show how to do it with Apple events if you
want; it's not hard.

HTH

has