Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit : > > May I ask you for extra information on how important is it to support > URLs, and if anything beyond file:/, http:// and https:// would need > to be supported ? ... > Also, can you give me a pointer to an explanation of what file:/ URLs > are useful for ? I read RFC 8089, but still did not get the point. ... > Since `eog http://example.com/image.png` will open the image, > shouldn't an "open" program ask to the server what the media type of > the URL is, and pass it to the default program able to handle it, > instead of just visualising in the browser ? Hi all, I hope I have not blasted you with my long answer and questions... At the moment, I think that I will go ahead with shipping `/usr/bin/open` as a symbolic link to `/usr/bin/run-mailcap` managed with the alternatives system, and state in its manual page that opening URLs is not supported for the moment but may be in the future. Regarding the redundancy with `/usr/bin/see`, I think that it is not an issue because 1) `see` was not intended to be provided by other packages and 2) its purpose is to visualise the contents of a document, while the purpose of `open` is to have the same effect as double-clicking on a document's icon. The difference is similar to the one between "click-spacebar" and "double-click" on macOS. Have a nice day, -- Charles
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
* Jeremy Bicha [201013 18:09]:
> On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich wrote:
> > Describing a clear benefit to having both open and see would help
> > immensely. Alternatively, convincing the mime-support authors that open
> > should replace see would also work.
>
> This thread is full of people who strongly prefer "open" over "see"
> ("see" is also little known). Add me to that list. In this case, I
> don't care whether other operating systems do it or not.
>
> I think "see" was used because "open" was not available. I don't know
> why you are so interested in having "see" go away. It could be removed
> but it's not clear at all to me that it needs to be removed at the
> same time "open" is added. (I don't see anything else that would want
> to use "see".)
Sorry if I gave the impression that I thought see should be removed.
That was not at all what I was saying, and I don't believe it should.
I was trying to identify how the new proposed implementation of "open"
was better or different than "see". My impression from this thread is
that the only issue is that a lot of people like the name "open" better,
and the current "see" is technically better (or at least as good) other
than a name preference. If that is the case, then there is probably a
much better solution than adding a new package to the archive that will
likely be installed in most of the same system configurations that
mime-support is.
The mime-support package seems to me to be the "right" place for "open"
and/or "see". If enough people have a strong opinion that Debian needs
an "open" that does what "see" currently does, I think a wishlist bug on
mime-support is the correct course of action. That would allow several
choices of implementation, the most likely (in my opinion) is adding
another symlink from open to run-mailcap and _possibly_ deprecating, but
leaving in the package, the "see" symlink.
If mime-support used "see" because "open" was unavailable at the time, I
would expect the mime-support maintainers to be very favorably inclined
to such a wishlist bug.
Adding even a very small package to the archive has a significantly
higher cost for the archive, the maintainers (including ftpmasters,
security, QA, etc.), and the end users than does adding one symlink in
an existing package.
Again, if the new "open" has features that "see" does not, let's
identify them so we can decide whether they belong in the mime-support
package or in a new package. If the only advantage is the name, I
cannot understand why anyone would object to at least approaching the
mime-support maintainers before plowing ahead with a new package.
...Marvin
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich wrote:
>
> * Noah Meyerhans [201013 00:54]:
> > "open" is a verb commonly used to describe the action of accessing a
> > file in Linux. You used it yourself above, and it's one of the most
> > prominent functions in the file API. It seems sensible to provide a
> > tool that matches the verb most commonly used to describe this action.
> >
> > The availability of
> > /usr/bin/open wouldn't preclude your use of whatever program you want to
> > use. What it would do is provide a convenient utility to support people
> > who don't (yet) have a preference for what application they want to use
> > to open a file. Maybe they have only basic needs, or are unfamiliar
> > with the file type and its associated commands. There are surely many
> > other reasons.
>
> Earlier in this thread, the program "see", part of mime-support, was
> mentioned as already providing this functionality. What does the
> proposed "open" do that "see" doesn't, or what does it do in a
> significantly different way that having both of them would be a benefit?
>
> So far, the only answer I have seen is that MacOS users are familiar
> with open. To me, this is not significant enough. A symlink or cover
> script that does simple massaging of the arguments, which invokes an
> existing utility like run-mailcap, would be better served by a
> macos-helpers package that can become a collection of utilities that
> help users coming from MacOS feel more comfortable in Linux. These
> wouldn't clutter the $PATH space for users who did not want them.
>
> The other difference that I remember being mentioned is that the
> proposed open only handled files, not URLs, but the author was willing
> to add that functionality to open if it was deemed popular.
>
> Describing a clear benefit to having both open and see would help
> immensely. Alternatively, convincing the mime-support authors that open
> should replace see would also work.
This thread is full of people who strongly prefer "open" over "see"
("see" is also little known). Add me to that list. In this case, I
don't care whether other operating systems do it or not.
I think "see" was used because "open" was not available. I don't know
why you are so interested in having "see" go away. It could be removed
but it's not clear at all to me that it needs to be removed at the
same time "open" is added. (I don't see anything else that would want
to use "see".)
Thanks,
Jeremy Bicha
> If open does not provide any real benefit over see, I would not want it
> to be in the transitive Depends or Recommends of a standard Debian
> desktop installation, which would then obviate its usefulness in the
> archive (except as a macos-helper as above).
>
> ...Marvin
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
* Noah Meyerhans [201013 00:54]: > "open" is a verb commonly used to describe the action of accessing a > file in Linux. You used it yourself above, and it's one of the most > prominent functions in the file API. It seems sensible to provide a > tool that matches the verb most commonly used to describe this action. > > The availability of > /usr/bin/open wouldn't preclude your use of whatever program you want to > use. What it would do is provide a convenient utility to support people > who don't (yet) have a preference for what application they want to use > to open a file. Maybe they have only basic needs, or are unfamiliar > with the file type and its associated commands. There are surely many > other reasons. Earlier in this thread, the program "see", part of mime-support, was mentioned as already providing this functionality. What does the proposed "open" do that "see" doesn't, or what does it do in a significantly different way that having both of them would be a benefit? So far, the only answer I have seen is that MacOS users are familiar with open. To me, this is not significant enough. A symlink or cover script that does simple massaging of the arguments, which invokes an existing utility like run-mailcap, would be better served by a macos-helpers package that can become a collection of utilities that help users coming from MacOS feel more comfortable in Linux. These wouldn't clutter the $PATH space for users who did not want them. The other difference that I remember being mentioned is that the proposed open only handled files, not URLs, but the author was willing to add that functionality to open if it was deemed popular. Describing a clear benefit to having both open and see would help immensely. Alternatively, convincing the mime-support authors that open should replace see would also work. If open does not provide any real benefit over see, I would not want it to be in the transitive Depends or Recommends of a standard Debian desktop installation, which would then obviate its usefulness in the archive (except as a macos-helper as above). ...Marvin
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Hi, On Tue, 13 Oct 2020, at 06:53, Noah Meyerhans wrote: > On Fri, Oct 09, 2020 at 12:14:23PM +0200, Stephan Seitz wrote: > > That’s why I need to know the different programs anyway. Why would I go for > > something like open which can only use one program for the file type? > You wouldn't, but that's not the point. The availability of > /usr/bin/open wouldn't preclude your use of whatever program you want to > use. What it would do is provide a convenient utility to support people > who don't (yet) have a preference for what application they want to use > to open a file. Maybe they have only basic needs, or are unfamiliar > with the file type and its associated commands. There are surely many > other reasons. I’m a potential user of "open", since I currently use xdg-open instead, and it’s longer to type. Very often I can’t or don’t want to remember what the binary of the application is called, especially in case of GNOME apps, which no longer use the application name in the UI: eog, evince etc. -- Cheers, Andrej
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Fri, Oct 09, 2020 at 12:14:23PM +0200, Stephan Seitz wrote: > > is probably very handy. Even more handy is the fact that you don't > > really need to learn the command name of your image viewer and your pdf > > viewer and your html viewer and you .dia viewer and your .mp3 player > > and every other viewer you might need to handle: only the 'open' > > command. > > I don’t know about that. Normally I use mupdf for pdf, but mupdf doesn’t > allow copy & paste. So if I want to do this, I need another pdf program. > > For my FLAC music I use audacious for my playlists and ogg123 for CLI > playing. > > If I want to open an image, I’m using qiv or gimp. > > Other rules apply for attachments in mutt, so mutt is using its own mailcap > definitions. "open" is a verb commonly used to describe the action of accessing a file in Linux. You used it yourself above, and it's one of the most prominent functions in the file API. It seems sensible to provide a tool that matches the verb most commonly used to describe this action. > That’s why I need to know the different programs anyway. Why would I go for > something like open which can only use one program for the file type? You wouldn't, but that's not the point. The availability of /usr/bin/open wouldn't preclude your use of whatever program you want to use. What it would do is provide a convenient utility to support people who don't (yet) have a preference for what application they want to use to open a file. Maybe they have only basic needs, or are unfamiliar with the file type and its associated commands. There are surely many other reasons. In order to support users who might care about what application they use, or who may wish to explore alternatives, it might be nice if the 'open' command could optionally print a list of programs that support the specified file's MIME type. noah
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On 2020-10-09 calumlikesapple...@gmail.com wrote: > On Thu, 2020-10-08 at 18:45 +0200, Andreas Metzler wrote: >> I do not get the reason for this change. Surely we do not expect >> people to manually type >> open penguin.jpeg [...] > I disagree. If you are developing an application, and are already > working within a terminal, you probably won't want to have to open up a > file browser and navigate to the right direction just to check if your > penguin logo is wearing a hat. In that case, typing > open penguin.jpeg > is probably very handy. [...] There is already see penguin.jpeg cu Andreas
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Thanks you Simon, Jérémie and everybody for your feedback.
> On Thu, 08 Oct 2020 at 05:54:27 +0900, Charles Plessy wrote:
> > /bin/open has been kindly freed a couple years ago (#732796) and I would
> > like to propose to repurpose it as a standard command for opening files,
> > like on Mac OS and NextStep before it.
Le Wed, Oct 07, 2020 at 11:17:34PM +0100, Simon McVittie a écrit :
>
> Is this intentionally a filename, and not a URI reference like the
> argument to xdg-open(1), the `gio open` subcommand in gio(1), and macOS
> open(1)? In particular, if we're using this name by analogy with the
> command in macOS, it doesn't seem great to be using a different invocation
> pattern.
I intentionally refrained from including URIs in my proposal, but I am
willing to consider it.
On my side, I never used open or xdg-open with a URL, so when I first
saw `xdg-open {file | URL}` in its manual page, I wondered how important
it was for the end user. Then, I looked at the manual page of `open` on
macOS, and saw that its first two lines only mention files and
directories. Thanks for the heads-up, now I know it also opens URLs.
For browsing an URL, I always call `firefox` directly. This is more a
habit than a conscious decision, and also I would not pretend to
represent the typical user. May I ask you for extra information on how
important is it to support URLs, and if anything beyond file:/, http://
and https:// would need to be supported ? Also, can you give me a
pointer to an explanation of what file:/ URLs are useful for ? I read
RFC 8089, but still did not get the point.
The reason I ask is that `run-mailcap` does not support URLs
at the moment. It would be possible to have emulate other tools by
passing HTTP urls to the default browser. Still, I wonder
if that is what a new user would expect. For instance, since `eog
http://example.com/image.png` will open the image, shouldn't an "open"
program ask to the server what the media type of the URL is, and pass it
to the default program able to handle it, instead of just visualising in
the browser ? But if the answer is "yes", I do not know how long it
would take me to implement it...
Le Wed, Oct 07, 2020 at 07:15:42PM -0400, Jeremy Bicha a écrit :
>
> You should be aware that Ubuntu implemented this idea 2 years ago.
> (I'm sure Ubuntu developers would love for this to be implemented by
> other distros or further upstream.)
>
> https://launchpad.net/bugs/1624022
I was not aware of the `browse` command implemented following the
Launchpad bug above; thank you for the heads-up. I just read the
discussion, and I see that `open` was also considered, but unfortunately
it was not free at that time. I think that `open` is a much better word
for the task. Also, it is not clear to me if `browse` intends to be an
alias to `xdg-open` only or something broader.
I the case of `open`, if there is an interest for the alternatives
system, I intend to give a low priority to the one pointing to
run-mailcap, so that on defauult Desktop systems, `open` would really
emulate what happens when the user double-clicks a file.
Have a nice day,
--
Charles Plessy
Akano, Uruma, Okinawa, Japan
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
(Re-added Charles to Cc as he asked in his original mail) Andreas Metzler writes: > On 2020-10-07 Charles Plessy wrote: >> Hello everybody, hello Debian freedesktop.org maintainers, > >> /bin/open has been kindly freed a couple years ago (#732796) and I would >> like to propose to repurpose it as a standard command for opening files, >> like on Mac OS and NextStep before it. > [...] > > I do not get the reason for this change. Surely we do not expect > people to manually type > > open penguin.jpeg > > in an xterm window, because they do not know how to handle the file. > They will usually *klick* on it and some infernal magic will invoke the > correct program, be it named xdg-open or geeqie. Not everybody is an expert, and I think the proposal is for the benefit of those that don't or don't want to know/remember the invocation of the right program for every specific data format and using a short, easy-to-remember name for this purpose. And Re: Stephan's mail: if you want to use a specific program to handle your data for a specific purpose, "open" is not intended for your use case. I'd say you can safely ignore it. Regards, Carsten
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Hi, On 09/10/20 3:44 pm, Stephan Seitz wrote: > but mupdf doesn’t allow copy & paste. So if I want to do this, I need > another pdf program. Actually its possible. Right click + drag and Cntrl C will do the copy. But it will not be perfect as other PDF reader and also depends on the file too. --abhijith signature.asc Description: OpenPGP digital signature
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Do, Okt 08, 2020 at 22:54:32 -0400, calumlikesapple...@gmail.com wrote: is probably very handy. Even more handy is the fact that you don't really need to learn the command name of your image viewer and your pdf viewer and your html viewer and you .dia viewer and your .mp3 player and every other viewer you might need to handle: only the 'open' command. I don’t know about that. Normally I use mupdf for pdf, but mupdf doesn’t allow copy & paste. So if I want to do this, I need another pdf program. For my FLAC music I use audacious for my playlists and ogg123 for CLI playing. If I want to open an image, I’m using qiv or gimp. Other rules apply for attachments in mutt, so mutt is using its own mailcap definitions. That’s why I need to know the different programs anyway. Why would I go for something like open which can only use one program for the file type? Many greetings, Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Hi, On Thu., Oct. 8, 2020, 00:30 Nicholas Guriev, wrote: > > On Wed, 2020-10-07 at 19:17 -0400, Jeremy Bicha wrote: > > On Wed, Oct 7, 2020 at 7:15 PM Jeremy Bicha wrote: > > > You should be aware that Ubuntu implemented this idea 2 years ago. > > > > Oh, I misread. Ubuntu used /usr/bin/browse but 'open' sounds a lot better. > > In my view, both of these words, "browse" or "open" do not look like a command > for computer. Their drawback is that they are too general. Well, we already have a /usr/bin/see symlink to run-mailcap, despite this critique...not many people seem to know about it though. I agree that "browse" has bad semantics, is confusing, and I'd additionally reject it as idiosyncratic. The proposed "open" symlink supports the specific case of users coming from MacOS, because we already have "see" as a solution to the problem. I'd like to see "see" documented in more places, and I don't see any obvious reasons why an additional symlink that provides familiarity for MacOS users is a bad thing, with one exception: is /usr/bin/open too much of a namespace grab? Should it be reserved for something more generic and low-level? Best, Nicholas
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Thu, 2020-10-08 at 18:45 +0200, Andreas Metzler wrote: > I do not get the reason for this change. Surely we do not expect > people to manually type > > open penguin.jpeg > > in an xterm window, because they do not know how to handle the file. > They will usually *klick* on it and some infernal magic will invoke > the correct program, be it named xdg-open or geeqie. I disagree. If you are developing an application, and are already working within a terminal, you probably won't want to have to open up a file browser and navigate to the right direction just to check if your penguin logo is wearing a hat. In that case, typing open penguin.jpeg is probably very handy. Even more handy is the fact that you don't really need to learn the command name of your image viewer and your pdf viewer and your html viewer and you .dia viewer and your .mp3 player and every other viewer you might need to handle: only the 'open' command. signature.asc Description: This is a digitally signed message part
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On 2020-10-07 Charles Plessy wrote: > Hello everybody, hello Debian freedesktop.org maintainers, > /bin/open has been kindly freed a couple years ago (#732796) and I would > like to propose to repurpose it as a standard command for opening files, > like on Mac OS and NextStep before it. [...] Hello, I do not get the reason for this change. Surely we do not expect people to manually type open penguin.jpeg in an xterm window, because they do not know how to handle the file. They will usually *klick* on it and some infernal magic will invoke the correct program, be it named xdg-open or geeqie. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Wed, 2020-10-07 at 19:17 -0400, Jeremy Bicha wrote: > On Wed, Oct 7, 2020 at 7:15 PM Jeremy Bicha wrote: > > You should be aware that Ubuntu implemented this idea 2 years ago. > > Oh, I misread. Ubuntu used /usr/bin/browse but 'open' sounds a lot better. In my view, both of these words, "browse" or "open" do not look like a command for computer. Their drawback is that they are too general. signature.asc Description: This is a digitally signed message part
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Wed, Oct 7, 2020 at 7:15 PM Jeremy Bicha wrote: > You should be aware that Ubuntu implemented this idea 2 years ago. Oh, I misread. Ubuntu used /usr/bin/browse but 'open' sounds a lot better. Thanks, Jeremy Bicha
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Wed, Oct 7, 2020 at 4:54 PM Charles Plessy wrote: > /bin/open has been kindly freed a couple years ago (#732796) and I would > like to propose to repurpose it as a standard command for opening files, > like on Mac OS and NextStep before it. You should be aware that Ubuntu implemented this idea 2 years ago. (I'm sure Ubuntu developers would love for this to be implemented by other distros or further upstream.) https://launchpad.net/bugs/1624022 Thanks, Jeremy Bicha
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Thu, 08 Oct 2020 at 05:54:27 +0900, Charles Plessy wrote:
> /bin/open has been kindly freed a couple years ago (#732796) and I would
> like to propose to repurpose it as a standard command for opening files,
> like on Mac OS and NextStep before it.
>
> As I maintain the mime-support package (soon to be split in `mailcap`
> and `media-types`, seee #964850), that provides the `run-mailcap`
> command to open files, I propose to provide /usr/bin/open as a symbolic
> link to it using the alternatives system.
>
> While `run-mailcap` has mutiple command-line options, I would like to
> define the "interface" of /usr/bin/open as having a single argument
> only, which is a path to a file or a directory. This would give the
> opportunity for other packages such as xdg-utils to provide
> /usr/bin/open if they wish so.
Is this intentionally a filename, and not a URI reference like the
argument to xdg-open(1), the `gio open` subcommand in gio(1), and macOS
open(1)? In particular, if we're using this name by analogy with the
command in macOS, it doesn't seem great to be using a different invocation
pattern.
(In most cases a relative or absolute path turns into a URI reference
that evaluates to the file:/// URI of the file you first thought of,
although there are differences - you'd have to prepend './' to filenames
with a ':' before '/', and filenames with '%' could be misinterpreted.)
If open(1) is defined to take only a single local file or directory
argument, and URI-based programs like xdg-open and gio open are allowed
to be alternatives for it, then I think it's inevitable that we will
have bugs where people incorrectly assume that open(1) is *always*
able to act on a URI argument, unless the URI-based programs are always
invoked via a wrapper something like this (untested):
#!/bin/bash
if [ "$#" != 1 ]; then
... error ...
fi
url="${1/[%]/%25/}"
case "$url" in
(/* | ./*)
;;
(*)
url="./$url"
;;
esac
exec xdg-open "$url"
Regards,
smcv
Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Hello everybody, hello Debian freedesktop.org maintainers, /bin/open has been kindly freed a couple years ago (#732796) and I would like to propose to repurpose it as a standard command for opening files, like on Mac OS and NextStep before it. As I maintain the mime-support package (soon to be split in `mailcap` and `media-types`, seee #964850), that provides the `run-mailcap` command to open files, I propose to provide /usr/bin/open as a symbolic link to it using the alternatives system. While `run-mailcap` has mutiple command-line options, I would like to define the "interface" of /usr/bin/open as having a single argument only, which is a path to a file or a directory. This would give the opportunity for other packages such as xdg-utils to provide /usr/bin/open if they wish so. I welcome your comments; please CC me as I am not subscribed. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
