[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: