Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
* Noah Meyerhans <noahm@debian.org> [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
Reply to: