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.n l>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.***********@h ccnet.nl

[Alex Martelli]

David Hughes <df*@forestfiel d.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.goo gle.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(pathTo File)}).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.a pp').open(FSSpe c(pathToFile))
HTH

[Alex Martelli]

has <ha*******@virg in.net> wrote:

df*@forestfield .co.uk (David Hughes) wrote in message news:<70******* *************** ***@posting.goo gle.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.

....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.a pp').open(FSSpe c(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.c om (Alex Martelli) wrote:

has <ha*******@virg in.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.a pp').open(FSSpe c(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.tombstoneze ro.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, thankyouverymuc h. 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.c om (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, thankyouverymuc h
...
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.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.

[Just]

In article
<m2************ @unique.fully.q ualified.domain .name.yeah.righ t>,
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