Hi,

more and more utilities use URL notation to pass around file names,
hence it would be very useful to have run-mailcap understand URL and do one of
two things:
- handle file:/... URL as normal files.
- pass along other kinds of URL (http://, ftp://, etc...) to
  sensible-browser.
This could be possibly controlled by a switch (e.g. --allow-url) for security
reasons.

I know that writing a wrapper-script to do this is pretty easy, but as
it might be of general interest, I thought it better to be directly in
mime-support.

Thanks, Eric

Le Tue, Jan 18, 2005 at 09:56:22AM +0100, Eric Lavarde a écrit :

Dear Eric,

for the first part of your proposition, I think that there is a serious
obstacle: with the mailcap system, it is not possible to determine if a program
would be able to use an URL to retreive a file.

For the second part, here is what we could do:

 - send a patch to the sensible-utils package, to add two lines in its
   mailcap file, where the media types x-scheme-handler/http and
   x-scheme-handler/ftp would be associated to the sensible-browser
   program.

 - Detect URLs passed to run-mailcap, and execute what /etc/mailcap proposes
   for the corresponding media type.

The problem I have with this approach is that x-scheme-handler media types
are not registered to the IANA.  As far as I know, they originate from the
Shared MIME-info Database specification.

http://standards.freedesktop.org/shared-mime-info-spec/

Perhaps it would be better to ask for comments on debian-devel before using
these unregistered media types outside the scope where thay have been developed
originally.

What do you think about this ?

Have a nice week-end,

Dear Eric,

do you still have interst for this bug report ?

Have a nice week-end,

Hi,

sorry, holiday came in between:

The idea was actually that there is a one-to-one relationship from a
file:-URL to a standard path by removing the prefix, something like the
following under bash:

	# the file:-URL format is not well defined or known
         URL[0]=file:///tmp/test.txt # absolute path, with empty server
field
         URL[1]=file:/tmp/test.txt   # absolute path, without server field
         URL[2]=file://tmp/test.txt  # relative path, with empty server
field
         URL[3]=file:tmp/test.txt    # relative path, without server field

         for i in "${URL[@]}"
         do # or in Perl s#^file:\(//\)?## (if I remember well)
                 i=${i#file://}
                 i=${i#file:}
                 echo "$i"
         done

And the resulting $i could just be handled like any file path given.
Eeh, to be honest, I think I had a much simpler (one could say hackish)
kind of approach in mind:

is the switch --allow-url set?
if yes, does the thing have a URL-kind of format (something like a match
on ^\w+://.*/.*$ - or more complex but still without knowledge of
specific URL-schemes)?
if yes, hand over to sensible-browser and forget about it.
if no, do as usual...

Thanks for taking care anyway,
Eric