desktop module (providing startfile as open, all platforms)

[pboddie]

BPO	1301512
Nosy	@merwok

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-07-15.15:20:11.927>
created_at = <Date 2005-09-23.16:30:52.000>
labels = ['library']
title = 'desktop module (providing startfile as open, all platforms)'
updated_at = <Date 2011-07-15.15:20:11.927>
user = 'https://bugs.python.org/pboddie'

bugs.python.org fields:

activity = <Date 2011-07-15.15:20:11.927>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2005-09-23.16:30:52.000>
creator = 'pboddie'
dependencies = []
files = []
hgrepos = []
issue_num = 1301512
keywords = ['patch']
message_count = 28.0
messages = ['48766', '48767', '48768', '48769', '48770', '48771', '48772', '48773', '48774', '48775', '48776', '48777', '48778', '48779', '48780', '48781', '48782', '48783', '48784', '48785', '48786', '48787', '48788', '48789', '48790', '48791', '48792', '140417']
nosy_count = 4.0
nosy_names = ['mwm', 'jjlee', 'pboddie', 'eric.araujo']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1301512'
versions = []

[pboddie]

Currently, in Python's standard library, there is
apparently no coherent, cross-platform way of getting
the user's environment to "open" files or resources
(ie. show such files in browsers, editors) when
requested by a Python program. There is an
os.startfile function which works for Windows, but no
equivalent function for other desktop environments -
the webbrowser module seems to employ alternative
mechanisms in choosing and running external
programs and presumably does not seek to provide
general support for non-URL resources anyway.

Since desktop environments like KDE and GNOME
provide mechanisms for running browsers and editors
according to the identified type of a file or resource,
just as Windows "runs" files or resources, it is
appropriate to have a module which accesses these
mechanisms. Attached is a simple module which
seeks to support KDE, GNOME and Windows - the
latter using the existing os.startfile support - and
which could be extended to support other desktop
environments such as Mac OS X, XFCE, CDE (along
with others deemed important and feasible enough to
support).

Note that this approach is arguably better than that
employed by the webbrowser module since most
desktop environments already provide mechanisms
for configuring and choosing the user's preferred
programs for various activities, whereas the
webbrowser module makes relatively uninformed
guesses (eg. opening Firefox on a KDE desktop
configured to use Konqueror as the default browser).

Note also that the startfile function is arguably
misplaced in the os module; thus, this functionality is
supplied as a new module rather than as a patch to
the os module, and the name of the function is
"open" (like in the webbrowser module) rather than
"startfile" which is a fairly Windows specific term. One
could also envisage the desktop module residing
within the os package to avoid top-level namespace
pollution.

Recent discussion in the comp.lang.python thread
"Open PDF" covering this issue can
be found here:
http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7

[jjlee]

Logged In: YES
user_id=261020

+1 on the idea, but a slight change to the implementation
for KDE...

I wrote a detailed bug report below, then discovered the
solution to what I assume is a bug.

Here's the solution: For KDE, use 'exec' instead of
'openURL' as the first argument to kfmclient.

Here's the detailed report:

I tried setting up KDE 3.2.2 to associate text files in the
order:

Emacs
KWrite
KEdit
Kate

I used Control Center->KDE Components->File Associations to
do that. All of those editors are installed on my machine.

Then I attempted to open this text file:

$ file /home/john/test.txt
/home/john/test.txt: ASCII text
$ cat /home/john/test.txt
hello, world

$

When I open it by clicking on it from a Konqueror directory
listing, GNU emacs running in an X11 window starts up, with
the specified file opened.

When I use your module:

$ python2.4
Python 2.4 (#1, Feb 19 2005, 23:54:54)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5,
propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import desktop
>>> desktop.open("/home/john/blocking.txt")
>>>

...it opens in Konqueror with some embedded editor (KEdit or
KWrite, I assume), not directly in any of the editors I
specified, and certainly not in emacs.

Same applies if I use a URL:

>> desktop.open("file:///home/john/test.txt")

This doesn't seem to be the intended behaviour of your module.

[jjlee]

Logged In: YES
user_id=261020

I guess there are probably security implications with using
kfmclient exec (risk of running arbitrary code)... but then
I guess the same applies to os.startfile().

[jjlee]

Logged In: YES
user_id=261020

Looking at the thread you reference, I guess it would be
nice if the desktop module supported returning a process handle.

On Windows, I imagine os.startfile could be extended in
Python 2.5 to use StartFileEx() (win32 function suggested by
Thomas Heller) and return a process handle. I guess it's
worth asking whether that's actually very useful without
ctypes or win32all, though.

Anybody know how you'd get a pid out of KDE or GNOME?

[pboddie]

Logged In: YES
user_id=226443

Configuring KDE to open different types of files requires
some magic that I don't fully understand. Nevertheless, I
find that if I create a shell script with executable
permissions then "kfmclient exec" will run that script,
whereas "kfmclient openURL" will ask whether I want to run
it first. That said, "kfmclient exec" probably has closer
semantics to the win32-supported os.startfile function.

I've uploaded a new version of the module which returns
the process identifier, along with some exception handling
around os.startfile.

See this page for related discussion of KDE and GNOME
application launching:
http://my.opera.com/community/forums/topic.dml?id=83890

See this thread for upcoming standards:
http://thread.gmane.org/gmane.linux.xdg.devel/2524

See this page for details of such standards:
http://www.freedesktop.org/Standards/mime-actions-spec

[pboddie]

Logged In: YES
user_id=226443

Other related material:
http://www.freedesktop.org/wiki/Software_2fpyxdg

[mwm]

Logged In: YES
user_id=93910

The code to support Mac OS X is:

While the commentary that webbrowser does it wrong is on
target, the proposed code resembles that more than one would
like. Both webbrowser and desktop poke around the system to
make a guess as to what application they should be using.
This is fine, so long as they guess right. The problems is
if they guess wrong. webbrowser allows for this by allowing
the user to specify a file opener in the environment
variable OPENER. I'd suggest supporting that. I started to
add support, then decided that

[mwm]

Logged In: YES
user_id=93910

The code to support Mac OS X is:

if sys.platform == 'darwin':
     cmd = ['open']

etc.

While the commentary that webbrowser does it wrong is on
target, the proposed code resembles that more than one would
like. Both webbrowser and desktop poke around the system to
make a guess as to what application they should be using.
This is fine, so long as they guess right. The problems is
if they guess wrong. There's an OSS replacement for open on
the Mac, and just because a box isn't running GNOME or KDE
doesn't mean it's Windows, or doesn't have a file opener.

webbrowser allows for this by allowing the user to specify a
file opener in an environment variable. Gnome (or was it
KDE?) uses OPENER for that. I'd suggest supporting that. I
started to add support, then noticed that cmd was a list of
strings, and you can't really specify that in an environment
variable, so it needs to be encoded somehow. I'm going to
leave that to someone more interested in the problem.

<mike

[jjlee]

Logged In: YES
user_id=261020

Oops, s/StartFileEx()/ShellExecuteEx()/

Paul: What are we actually trying to do here? 1) Open
arbitrary files (possibly by means of a URL) using the
method that the desktop user has configured his desktop /
OS? Or 2) open arbitrary URLs in the web browser he has
configured (possibly making use of GUI components embedded
in the browser)? Or 3) something else?

If 1) (which is what I had gathered from your initial
comment and the c.l.py thread you referenced), then I guess
ShellExecute (os.startfile) is right, as is kfmclient exec,
and we just have to accept there are security implications
that need to be borne in mind and acted upon appropriately
(I'm not certain what that entails). Are there really major
security differences between kfmclient exec and ShellExecute
here?

If 2). then it seems that we're doing two different things
on the two different desktops we're talking about: kfmclient
has openUrl, but ShellExecute doesn't have any equivalent (I
assume the "explore" verb always lands you in IE / Windows
Explorer, never firefox, for example). Perhaps unavoidable,
but weakens the case for the module.

[pboddie]

Logged In: YES
user_id=226443

Several good points, Mike! (And I wondered where your
own open program would fit in here.) The major problem
with webbrowser is that it either uses obsolete techniques
or just leaves most of the work to the caller. Moreover, it
has to keep pace with the range of applicable programs,
which is more work than just keeping up with relevant
desktop environments even for such a restricted domain.

Mike, John: the motivation for this module was that
os.startfile hooks into the Windows API in order to follow
the user preferences reliably stored elsewhere, yet there
aren't equivalent functions for other systems, despite the
fact that such functions have been around for some time. I
think "kfmclient exec" may be the way to go for KDE, by the
way.

As for Windows, I do recall entering URLs at the command
line, but I don't recall whether Windows observed my
desktop preferences, although I do seem to remember it
launching Acrobat Reader for remote PDF resources.
Someone else would have to verify that, though.

[mwm]

Logged In: YES
user_id=93910

open is a desktop-independent variation on gnome-open and
kfmclient. So it's something that desktop could be set up to
run, using cmd = ["open", url].

On the other hand, it also exposes an API to Python progams,
so you could (in theory) replace Unix-specific parts of
desktop with (using the development version):

from open import run
run(filename, have = ['open'])

except that it'd use the users "open" preferences instead of
their desktop preferences. This is why I proposed the OPENER
environment variable. I don't run a desktop, so the proposed
version would default to trying os.startfile. I'd rather it
use open.

<mike

Sorry 'bout the previous double post. I accidently tabbed to
the submit button...