Repository navigation
Add shutil.open #47427
Description
| BPO | 3177 |
|---|---|
| Nosy | @ronaldoussoren, @tebeka, @pitrou, @larryhastings, @giampaolo, @benjaminp, @mcepl, @merwok, @bitdancer, @smarnach, @Fak3, @danpla |
| Files |
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 = None
created_at = <Date 2008-06-23.11:38:23.901>
labels = ['type-feature', 'library']
title = 'Add shutil.open'
updated_at = <Date 2018-03-02.17:06:15.586>
user = 'https://bugs.python.org/ganadist'bugs.python.org fields:
activity = <Date 2018-03-02.17:06:15.586>
actor = 'Socob'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2008-06-23.11:38:23.901>
creator = 'ganadist'
dependencies = []
files = ['10715', '25310', '25311', '25312', '25315', '25317', '25319', '25332', '26624']
hgrepos = []
issue_num = 3177
keywords = ['patch']
message_count = 62.0
messages = ['68623', '68650', '68664', '140059', '140275', '140276', '140280', '140283', '140415', '140416', '140418', '140419', '157216', '157246', '157247', '157258', '159000', '159001', '159004', '159005', '159006', '159007', '159008', '159009', '159010', '159017', '159020', '159029', '159030', '159034', '159037', '159038', '159039', '159043', '159044', '159051', '159056', '159058', '159059', '159062', '159063', '159064', '159065', '159068', '159069', '159121', '159505', '159507', '161569', '161613', '161631', '161687', '161688', '161837', '161852', '161853', '161854', '161858', '167011', '310214', '311549', '311552']
nosy_count = 19.0
nosy_names = ['ronaldoussoren', 'tebeka', 'pitrou', 'larry', 'giampaolo.rodola', 'benjamin.peterson', 'mcepl', 'eric.araujo', 'ganadist', 'Arfrever', 'r.david.murray', 'cvrebert', 'rosslagerwall', 'smarnach', 'Roman.Evstifeev', 'Hobson.Lane', 'plakhotich', 'Socob', 'amirjn']
pr_nums = []
priority = 'low'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue3177'
versions = ['Python 3.3']
Activity
ganadist commentedon Jun 23, 2008
Currently, os.startfile is implemented in Win32 only, but there are
command line tools in Unix and MacOSX that have same behavior.
As a result of http://portland.freedesktop.org, unix desktop has command
line tool named "xdg-open"
(http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html).
And MacOSX has 'open'
(http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/open.1.html)
command, and it can be used in same condition.
benjaminp commentedon Jun 23, 2008
Those commands can be easily used through the subprocess module.
However, if a patch is provided, it could be accepted.
[-]os.startfile implement in posix and MacOSX[/-][+]implement os.startfile on posix and MacOSX[/+]ganadist commentedon Jun 24, 2008
I implemented os.startfile on posix and MacOSX as you said.
but it need more work to handle error.
rosslagerwall commentedon Jul 9, 2011
Closed bpo-12522 as a duplicate.
It contains a link to a discussion on python-ideas requesting the feature.
merwok commentedon Jul 13, 2011
I’m not sure we want to copy the Windows startfile call for other OSes. The os module is designed to wrap system-level calls, masking OS differences (for sendfile, for example) but not going further; it’s up to other modules (like shutil) to build more convenient APIs on top of what os provides. xdg-open is a program that’s used to open files or URIs, but it does not provide other actions like Windows’ startfile does (edit, print, etc.), nor is it backed by a system call. For these reasons, I think it’s inappropriate to implement os.startfile for non-Windows systems. People can use subprocess to run open or xdg-open.
giampaolo commentedon Jul 13, 2011
+1 on what Eric just said.
See bpo-10882 and msg 126049
merwok commentedon Jul 13, 2011
So, unless someone wants to turn this request into “Add shutil.open”, I’ll close it in a few days. (I haven’t found the original discussion; if someone could add a link to the archives on mail.python.org or copy relevant quotes, it could help.)
cool-RR commentedon Jul 13, 2011
Eric, I have no problem with this function being placed in
shutilinstead ofos, as long as it's implemented and it's in the standard library, and people don't have to use subprocess to run open or xdg-open themselves as I currently do.So I have no problem with renaming this bug to "Add shutil.open".
merwok commentedon Jul 15, 2011
This new function would call os.startfile on Windows, xdg-open where applicable, and open on Mac OS X (using a subprocess for these last two).
I found the python-ideas thread: http://mail.python.org/pipermail/python-ideas/2011-July/010674.html
There was only limited support.
[-]implement os.startfile on posix and MacOSX[/-][+]Add shutil.open[/+]vstinner commentedon Jul 15, 2011
Why did you add this dependency? For example, subprocess is able to locate a program if the program has no full path. We don't need a which function.
merwok commentedon Jul 15, 2011
See also lengthy discussion on bpo-1301512.
43 remaining items
merwok commentedon May 29, 2012
The latest discussion on this thread does not match my UNIX user model.
tl;dr: shutil.whatever should call startfile(..., 'edit') or xdg-open; other actions implemented by startfile are not cross-platform.
This makes sense from an os.startfile perspective, but not for an xdg-open user. xdg-open (and shutil.whatever in my eyes) only starts an application with the passed argument; that’s it. There is no execute action because that’s done otherwise (in Python, with subprocess and os.exec*; in the shell, with program invocation (i.e. “program” or “/full/path/to/file”) using shebangs or binfmt-format). So in my mental model, using xdg-open to have a file or URI opened by a configured application (which can be graphical or command-line) has nothing to do with executing a file.
(There was an older system on UNIX named mailcap where you could register console and GUI actions for different actions, like edit and print, but it’s not used by current graphical mail clients like Thunderbird or by the xdg-open system, so I would not consider it at all.)
merwok commentedon May 29, 2012
Note that my suggestion has an inconvenient on Windows. Take the example of HTML files; on an UNIX system I would decide whether I want them to be opened with my text editor or my web browser; I’d choose web browser because I launch my text editor from a shell. On Windows though you would register your web browser for default action and your text editor for the edit action; this deliberate configuration would not be respected if we implement shutil.whatever with os.startfile(..., 'edit').
merwok commentedon May 29, 2012
(A last, very minor thing: please trim or remove quoted text when replying with the email interface (or on mailing lists); it puts unneeded wall of texts that reader waste time scanning, in case there were inline replies. Thanks in advance.)
HobsonLane commentedon May 29, 2012
shutil.whatever with os.startfile(..., 'edit').
That's why I thought an 'auto' option might be useful--to allow the caller
to indicate that they want to respect the OS settings for open/run, if
possible.
ronaldoussoren commentedon Jul 31, 2012
MacOSX provides functionality simular to os.startfile in the LaunchServices framework.
I've tried to prototype a startfile implementation using this framework, (see bpo-3177-os_startfile_macosx.txt) but I'm not too happy about it because the APIs don't actually work as expected.
In particular:
The patch implements "open" (default), "edit", "print" and
"explore" actions.
"open" and "explore" work fine
"edit" does not work as I'd expect because the function used
to retrieve the default editor for a file returns the default
application that can open the file, not necessarily one that
claims to be an editor for the file-type. As an example,
'os.startfile("file.html", "edit")' starts Safari instead of
an editor.
"print" works for some file type, but not others (depending on
whether or not the target application implements the required
AppleScript API)
"execute" is untested, I haven't found an application yet that claims
this role.
Other notes:
This patch links Python with the ApplicationServices framework
(which contains the LaunchServices framework)
Because the API uses Apple's application frameworks users might get
annoying crashes when calling this function in a subprocess.
The code attached code is a prototype, it should be correct w.r.t.
resource management, but isn't fully baked yet. One example of that
is the use of a generic RuntimeError exception to signal problems,
others are the lack of documentation and tests.
danpla commentedon Jan 17, 2018
xdg-open is just a shell script that calls desktop-specific launchers. The behavior of these launchers is very different when it comes to executables. There is no guarantee that calling xdg-open for a script will open it for editing.
For example, there are 3 launchers on my XFCE machine: exo-open (native for XFCE), gvfs-open (GNOME), and kde-open. When called with a .py script with shebang line and executable bit set, exo-open and kde-open open text editor, but gvfs-open launches the script. When called for a real exe, exo-open and gvfs-open launch it, but kde-open brings a message box saying that the exe will not be started for safety reasons.
The patch raises NoAssociatedApplicationError when xdg-open returns 3, but this error code actually means that a launcher was not found.
amirjn commentedon Feb 3, 2018
same problem here
amirjn commentedon Feb 3, 2018
dbarnett commentedon Sep 15, 2024
Hello from 2024! 👋
Any hope of getting a shutil.open implementation landed still? It looks like this issue stalled out after 2012...
It's been discussed on a popular StackOverflow question, and there's now a universal-startfile package on PyPI attempting to offer the same thing.
merwok commentedon Sep 16, 2024
I don’t think there is a well thought-out proposal, or a big need for this.
Third-party modules can fill the need.
dbarnett commentedon Sep 16, 2024
What's the rationale for "not a big need"? To me the popular StackOverflow questions (+ lots of dupes of it) suggest otherwise.
I was actually considering to publish my own third-party module for it, but would prefer to make it a drop-in polyfill with whatever's planned for standard library here (and the half-working os.startfile) instead of trying to freehand a signature myself.
@ALL could anyone help direct me to min viable behavior if I were volunteering to implement it in a module?
dbarnett commentedon Sep 22, 2024
K, I've implemented a quick https://pypi.org/project/shopen/ with my understanding of what a shutil.open should offer. IMO it'd still be great to have those batteries come included with python, but for now I can iterate there on ironing out the wrinkles.
zed commentedon Nov 8, 2024
Often
shutil_open = webbrowser.openworks.