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]

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

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

[Alex Martelli]

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

David Hughes <dfh@forestfiel d.co.uk> wrote:
[color=blue]
> 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.[/color]

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]

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

dfh@forestfield .co.uk (David Hughes) wrote in message news:<70bb9f8d. 0411040250.1f4a c1a@posting.goo gle.com>...[color=blue]
> 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?[/color]

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.sanderson/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]

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

has <has.temp2@virg in.net> wrote:
[color=blue]
> dfh@forestfield .co.uk (David Hughes) wrote in message[/color]
news:<70bb9f8d. 0411040250.1f4a c1a@posting.goo gle.com>...[color=blue][color=green]
> > 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?[/color]
>
> Using os.system to execute open is pretty simple, as other folks have
> pointed out.[/color]

....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:-(.

[color=blue]
> replacement. Much improved, though unfinished, AE support is available
> from my site:
>
> http://freespace.virgin.net/hamish.s...appscript.html[/color]
...[color=blue]
> from appscript import *
> app('TextEdit.a pp').open(FSSpe c(pathToFile))[/color]

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]

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

On Fri, 5 Nov 2004 08:41:31 +0100,
aleaxit@yahoo.c om (Alex Martelli) wrote:
[color=blue]
> has <has.temp2@virg in.net> wrote:[/color]
[color=blue][color=green]
>> replacement. Much improved, though unfinished, AE support is available
>> from my site:
>>
>> http://freespace.virgin.net/hamish.s...appscript.html[/color]
> ...[color=green]
>> from appscript import *
>> app('TextEdit.a pp').open(FSSpe c(pathToFile))[/color][/color]
[color=blue]
> OK, but how does one handle the *waiting*, so as to proceed only when
> TextEdit is done editing that document?[/color]
[color=blue]
> "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).[/color]

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.
[color=blue]
> 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;-)...[/color]

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]

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

Dan Sommers <me@privacy.net > wrote:
...[color=blue][color=green]
> > "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).[/color]
>
> 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:[/color]

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.
[color=blue]
> 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?[/color]

The application should somehow be notified after point (4); any earlier
time would be inappropriate.
[color=blue]
> 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.[/color]

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.

[color=blue][color=green]
> > 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;-)...[/color]
>
> 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. ;-)[/color]

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]

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

On Fri, 5 Nov 2004 13:35:31 +0100,
aleaxit@yahoo.c om (Alex Martelli) wrote:
[color=blue]
> Dan Sommers <me@privacy.net > wrote:
> ...[color=green][color=darkred]
>> > "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).[/color]
>>
>> 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:[/color][/color]
[color=blue]
> 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.[/color]

Agreed. My editor of choice these days is emacsclient.

[ typical multiple-user-GUI-application interaction scenario snipped ]
[color=blue][color=green]
>> 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?[/color][/color]
[color=blue]
> The application should somehow be notified after point (4); any
> earlier time would be inappropriate.[/color]

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.
[color=blue][color=green][color=darkred]
>> > 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;-)...[/color]
>>
>> 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. ;-)[/color][/color]
[color=blue]
> 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
> ...[/color]

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).
[color=blue]
> 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.[/color]

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).
[color=blue]
> Alex[/color]

Regards,
Dan

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

[Just]

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

In article
<m2u0s4sb6e.fsf @unique.fully.q ualified.domain .name.yeah.righ t>,
Dan Sommers <me@privacy.net > wrote:
[color=blue][color=green]
> > 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.[/color]
>
> 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).[/color]

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]

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

Just <just@xs4all.nl > wrote:
...[color=blue]
> 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"[/color]

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]

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

Dan Sommers <me@privacy.net > wrote:
...[color=blue][color=green]
> > 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.[/color]
>
> Agreed. My editor of choice these days is emacsclient.[/color]
[color=blue][color=green]
> > The application should somehow be notified after point (4); any
> > earlier time would be inappropriate.[/color]
>
> 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.[/color]

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...
[color=blue]
> 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).[/color]

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.

[color=blue]
> 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).[/color]

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]

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

In article <1gms4py.c7p5cj eee3clN%aleaxit @yahoo.com>,
aleaxit@yahoo.c om (Alex Martelli) wrote:

[snip][color=blue]
> 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.[/color]


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 NSPrincipalClas s in the Info.plist file, exiting


Doug

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

[Aslak Raanes]

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

Alex Martelli <aleaxit@yahoo. com> wrote:
[color=blue]
> 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...? )[/color]

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]

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

aleaxit@yahoo.c om (Alex Martelli) wrote[color=blue]
> has <has.temp2@virg in.net> wrote:
>[color=green][color=darkred]
> > > 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?[/color]
> >
> > Using os.system to execute open is pretty simple, as other folks have
> > pointed out.[/color]
>
> ...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:-(.[/color]

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]

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

In article <1gmsdlv.1fwilz keutnhjN%aleaxi t@yahoo.com>,
aleaxit@yahoo.c om (Alex Martelli) wrote:
[color=blue]
> 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.[/color]

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