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