/usr/bin/open now in use through the alternatives system.

[Stig Sandbeck Mathisen]

Charles Plessy <plessy at debian.org> writes:

> I went ahead and uploaded to Sid mime-support version 3.68, which
> provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap
> using the alternatives system, at a priority of 30. I welcome other
> alternatives.

This is good news. Thank you. :)

I've used "open" as an alias for "xdg-open" for a long time. This
command would probably also be appropriate as an alternative for "open".

> At the moment the manual page of open is simply the one of
> run-mailcap, but I plan to provide a specific one. Given the lack of
> answer to my previous email (quoted below), I have not implemented URL
> support in /usr/bin/run-mailcap.
>
>> 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.

When handling various methods for fetching content, being explicit about
the scheme ("This is a file") is more robust than being implicit ("As a
last resort, this will be regarded as a file"). Using "file" a default
scheme makes sense if nothing else is specified.

File URIs may be returned by other applications. When using "tracker
search" to search the content of my local files, all results are
returned with "file:///" URIs. Being able to pipe that output to "open"
would be awesome.

>> > 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 ?

I would much rather trust the local "file" command and magic database
instead. The remote server will most likely return a proper content
type, but trusting remote servers to influence which command to open the
file locally will have an impact on security.

-- 
Stig Sandbeck Mathisen
Debian Developer