[issue3177] Add shutil.open

Change by Socob <206a8...@opayq.com>: -- nosy: +Socob ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue3177] Add shutil.open

amirjn added the comment: same problem here -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue3177] Add shutil.open

amirjn added the comment: same problem here -- nosy: +amirjn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue3177] Add shutil.open

Change by Matej Cepl : -- nosy: +mcepl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[issue3177] Add shutil.open

Daniel Plakhotich added the comment: > tl;dr: shutil.whatever should call startfile(..., 'edit') or xdg-open; other > actions implemented by startfile are not cross-platform. xdg-open is just a shell script that calls desktop-specific launchers. The behavior of these launchers is very differe

[issue3177] Add shutil.open

Ronald Oussoren added the comment: MacOSX provides functionality simular to os.startfile in the LaunchServices framework. I've tried to prototype a startfile implementation using this framework, (see issue3177-os_startfile_macosx.txt) but I'm not too happy about it because the APIs don't act

[issue3177] Add shutil.open

Hobs added the comment: 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. -- ___ Python tracker

[issue3177] Add shutil.open

Éric Araujo added the comment: (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.) -- __

[issue3177] Add shutil.open

Éric Araujo added the comment: 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.

[issue3177] Add shutil.open

Éric Araujo added the comment: 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. > Well, so how about on UNIX shutil.launch (or whatever

[issue3177] Add shutil.open

Hobs added the comment: Then they or we can add Konqueror, etc to the options that are 'try'ed for the 'view' option. Worst case they get a terminal cat of the file instead of an error message or unintended action (like running a script). What exactly are you proposing to do when execute is Fals

[issue3177] Add shutil.open

Larry Hastings added the comment: > In Linux we could `try` nautilus then Mozilla > (file://.../containing_folder) then fall back to a shell > `cd && ls` if no browser is available, raising NotImplemented > if all else fails... until someone implements for that > user's platform particulars. Wh

[issue3177] Add shutil.open

Hobs added the comment: In Linux we could `try` nautilus then Mozilla (file://.../containing_folder) then fall back to a shell `cd && ls` if no browser is available, raising NotImplemented if all else fails... until someone implements for that user's platform particulars. Likewise on OSX, Mac, e

[issue3177] Add shutil.open

Larry Hastings added the comment: > Could even add an `operation` parameter to let the caller > select actions, > [...] > operation in ['auto', 'run', 'edit', 'display', 'browse', > 'explore', 'share', 'send', 'like', 'email', 'open', 'xdg-open', > ...] # can be incrementally added/implemented

[issue3177] Add shutil.open

Hobs added the comment: Could even add an `operation` parameter to let the caller select actions, including 'auto' implemented as Larry suggests. Sometimes you feel like trusting the user's xdg-open preferences/settings. Sometimes you don't. Easy enough to let the caller choose, rather than the

[issue3177] Add shutil.open

Larry Hastings added the comment: > As an example, ``os.startfile("a.py")`` will usually run `a.py` > in the Python interpreter, while ``xdg-open a.py`` it will > usually open the source code in an editor on Linux. Well, so how about on UNIX shutil.launch (or whatever it's called) first checks

[issue3177] Add shutil.open

Hobs added the comment: Had no idea. Sounds like a good place for it. On Apr 28, 2012 6:54 AM, "Miki Tebeka" wrote: > > Miki Tebeka added the comment: > > Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there. > > -- > nosy: +tebeka > > ___

[issue3177] Add shutil.open

Miki Tebeka added the comment: Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there. -- nosy: +tebeka ___ Python tracker ___ ___

[issue3177] Add shutil.open

Hobs added the comment: I can see why this partial implementation of `operation` in this ver seems useless. But it is a placeholder for eventually providing Linux/Mac users with the same functionality as windows. The os.startfile() or shutil.launch() function can easily fill the gap left by the

[issue3177] Add shutil.open

Changes by Chris Rebert : Added file: http://bugs.python.org/file25332/shutil_open.patch ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue3177] Add shutil.open

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue3177] Add shutil.open

Antoine Pitrou added the comment: > I'm not a lawyer (duh), but my understanding is that *looking* at GPL > code (as opposed to proprietary code, where someone might sue you > about it and not looking is a good defense) is OK, you just can't copy > it. You could probably copy a one- or two-line

[issue3177] Add shutil.open

R. David Murray added the comment: I'm not a lawyer (duh), but my understanding is that *looking* at GPL code (as opposed to proprietary code, where someone might sue you about it and not looking is a good defense) is OK, you just can't copy it. -- ___

[issue3177] Add shutil.open

Chris Rebert added the comment: >> The semantics of "associated application" change considerably from >> operating system to operating system. As an example, >> ``os.startfile("a.py")`` will usually run `a.py` in the Python >> interpreter, while ``xdg-open a.py`` it will usually open the source

[issue3177] Add shutil.open

Hobs added the comment: Yea, I hosed up the path quoting in a misguided attempt at shortening for 80-col line-wrapping. Yours is better, will revert. On Tue, Apr 24, 2012 at 2:09 AM, Chris Rebert wrote: > > Chris Rebert added the comment: > > Also: > > The FileNotFoundErrors quote the path tw

[issue3177] Add shutil.open

Chris Rebert added the comment: The xdg-open source code (http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open ) shows that exit code 4 is used whenever an invocation of another opener script (e.g. kde-open, gnome-open) fails for any reason besides said script not being installed.

[issue3177] Add shutil.open

Chris Rebert added the comment: Also: The FileNotFoundErrors quote the path twice: Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) >>> path = "/foo/bar" >>> print "Path '%s' may not exist" % repr(path) Path ''/foo/bar'' may not exist The ValueError error message isn't grammat

[issue3177] Add shutil.open

Hobs added the comment: Because that's how I caused the exception in Ubuntu--shutil.launch('file_that_doesnt_exist'). That's why I changed the message to "file may not exist" for both 2 and 4, but should probably prove that 2 sometimes happens when the file does exist (like with permission or vi

[issue3177] Add shutil.open

Chris Rebert added the comment: Hobs, why is exit code 4 of xdg-open (which the manpage describes as the extremely generic "The action failed.") interpreted as FileNotFoundError in your new version? -- ___ Python tracker

[issue3177] Add shutil.open

Chris Rebert added the comment: >> ENOSYS was the closest approximation I could find. Thoughts? Custom >> error class? Different errno? Something else? > > Why not ValueError? Because the value they provided was perfectly valid (the file/directory *did* exist), so the caller's request was reas

[issue3177] Add shutil.open

Hobs added the comment: I'll be happy to code, test, and use the new .() function wherever it ends up and whatever it is named... but... > Initially this issue was about implementing a startfile-equivalent on > posix. But if you have to add a gui option to startfile to not lanuch > a

[issue3177] Add shutil.open

Hobs added the comment: Last patch was invalid and untested. New patch passes `make patchtest`, but still doing the full test suite on Windows and Linux. Still unsure if I raised the right exceptions with the right arguments. -- Added file: http://bugs.python.org/file25317/shutil_ope

[issue3177] Add shutil.open

Éric Araujo added the comment: > The semantics of "associated application" change considerably from > operating system to operating system. As an example, > ``os.startfile("a.py")`` will usually run `a.py` in the Python > interpreter, while ``xdg-open a.py`` it will usually open the source > co

[issue3177] Add shutil.open

Sven Marnach added the comment: The semantics of "associated application" change considerably from operating system to operating system. As an example, ``os.startfile("a.py")`` will usually run `a.py` in the Python interpreter, while ``xdg-open a.py`` it will usually open the source code in

[issue3177] Add shutil.open

R. David Murray added the comment: Initially this issue was about implementing a startfile-equivalent on posix. But if you have to add a gui option to startfile to not lanuch a GUI, and your real goal is a consistent way to launch non-gui programs on posix, then I don't see that this is abou

[issue3177] Add shutil.open

Hobs added the comment: New patch incorporates improvements from pitrou, cvrebert, r.david.murray, eric.araujo, cool-RR -- Added file: http://bugs.python.org/file25315/shutil_open.patch ___ Python tracker

[issue3177] Add shutil.open

Hobs added the comment: @Éric Thanks for clearing up my misunderstanding of os and shutil. I get it now. I'm sure you know this, and it's clear you agree with changing the name, but just to add fire to your resolve, the difference between shutil.open() and the other `*.open()` modules you ment

[issue3177] Add shutil.open

Éric Araujo added the comment: Please trust us that this is our policy. os is a thin wrapper only. -- ___ Python tracker ___ ___ Pyth

[issue3177] Add shutil.open

Hobs added the comment: Does no one like "os.startfile" as a home for this? Besides myself and the original 2008 proposer, of course. Can anyone explain to us newbies why it's a bad idea to have the cross-platform module do things identically across platforms? @David, `shutils.wmopen` locks yo

[issue3177] Add shutil.open

R. David Murray added the comment: Launch is far better than open for this, I think. If someone can come up with an even better name, that would be good. But I would not like to use open for this function, because it does not behave like other open functions. The one exception I know of is

[issue3177] Add shutil.open

Éric Araujo added the comment: Thanks for relaunching this! > I'm not sure I understand why this was moved to shutil.open. It seems > appropriate to try to accomplish what > os.startfile() does in a cross-platform way. Don't many of the other os.* > calls do this--check os.name and > then "do

[issue3177] Add shutil.open

Antoine Pitrou added the comment: > ENOSYS was the closest approximation I could find. Thoughts? Custom > error class? Different errno? Something else? Why not ValueError? -- nosy: +pitrou ___ Python tracker _

[issue3177] Add shutil.open

Chris Rebert added the comment: No, it isn't. Changing the `IOError(errno.ENOENT, "...`s to `FileNotFoundError("...`s would half fix it. The other half, the `OSError(errno.ENOSYS)`s, has a FIXME for what's the right error to raise in that case ("no application associated with files of this t

[issue3177] Add shutil.open

R. David Murray added the comment: Is the error raising PEP 3151 compliant? -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue3177] Add shutil.open

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue3177] Add shutil.open

Changes by Ram Rachum : -- nosy: -cool-RR ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue3177] Add shutil.open

Chris Rebert added the comment: `operation` seems questionable. IMO, the verbs seem stronger / more important than mere optional suggestions (particularly "open" vs. "edit" for files with read-only viewers), and only Windows supports them (so anyone requiring that feature might as well just u

[issue3177] Add shutil.open

Chris Rebert added the comment: > # or os.name == 'mac' ??? Nope, that refers to retro Mac OS 9 (and probably lower). Mac OS X is 'posix' for os.name purposes. -- ___ Python tracker __

[issue3177] Add shutil.open

Hobs added the comment: Implement shutil.launch() & fix minor shutil.disk_usage() doctext typo Name changed from shutil.open to shutil.launch due to namespace conflict with open() builtin within the shutil module and for users that do from shutil import * On Ubuntu Oneiric Linux shutil.l

[issue3177] Add shutil.open

Hobs added the comment: Test passes on Ubuntu Oneiric Linux and 'open' action appropriately defaults to launching an editor for my particular OS settings. Tests on Windows in work. -- Added file: http://bugs.python.org/file25311/shutil_launch.py __

[issue3177] Add shutil.open

Chris Rebert added the comment: Here's a quick stab at 2/3rds of an implementation, and some docs. -- Added file: http://bugs.python.org/file25310/shutil_open.py ___ Python tracker _

[issue3177] Add shutil.open

Hobs added the comment: @eric.araujo, @giampaolo.rodola, (http://bugs.python.org/issue3177#msg140275) I'm not sure I understand why this was moved to shutil.open. It seems appropriate to try to accomplish what os.startfile() does in a cross-platform way. Don't many of the other os.* calls do

[issue3177] Add shutil.open

Chris Rebert added the comment: >> (2) Target file doesn't exist >> (4) No application is associated with the file type in question > I think that instead of mapping error codes to custom exceptions, which is > fragile and not trivial to maintain, we should just catch stderr and raise > someth

[issue3177] Add shutil.open

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue3177] Add shutil.open

Éric Araujo added the comment: >> [...] do we get ENOENT if xdg-open exists but not the file?). > It's unambiguous. Python itself never opens the target file, it just passes > the filepath string > along to the xdg-open command. If Popen raises EnvironmentError, then > xdg-open could not be >

[issue3177] Add shutil.open

STINNER Victor added the comment: > (1) Platform doesn't support this feature -> raise NotImplemented It's better to not define the function if the platform doesn't support the feature. -- ___ Python tracker _

[issue3177] Add shutil.open

Chris Rebert added the comment: > The alternative is to call Popen(['xdg-open', etc.]) and check if we get > ENOENT, but I don’t know if this would be non-ambiguous (for example, do we > get ENOENT if xdg-open exists but not the file?). It's unambiguous. Python itself never opens the target f

[issue3177] Add shutil.open

Changes by Roman Evstifeev : -- nosy: +Roman.Evstifeev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue3177] Add shutil.open

Éric Araujo added the comment: >> dependencies: + Finding programs in PATH, adding shutil.which > 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. While the Windows API call is part of Windo

[issue3177] Add shutil.open

Éric Araujo added the comment: See also lengthy discussion on #1301512. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue3177] Add shutil.open

STINNER Victor added the comment: > dependencies: + Finding programs in PATH, adding shutil.which 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. -- nosy: +haypo

[issue3177] Add shutil.open

Éric Araujo added the comment: > 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. This new function would call os.startfile on Windows, xdg-open where applicable, and open on Mac OS X