* Noah Meyerhans <no...@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