Re: Funny action on "opening" a pdf document

[Theodore Kilgore <kilgota banach math auburn edu>]

On Sat, 19 Jan 2013, Piotr Ozarowski wrote:

> [Theodore Kilgore, 2013-01-18]
> > On Fri, 18 Jan 2013, Piotr Ozarowski wrote:
> >
> > > [Theodore Kilgore, 2013-01-18]
> > > > "xdg-open opens a file or URL in the user's preferred application" 
> > > > explicitly mentioning "a file or a url" and then it says 
> > > > "If a file is provided the file will be opened in the preferred 
> > > > application for files of that type." These words would indicate that it is 
> > > > going to open a file by doing something to the file, not by doing the 
> > > > extraneous act of starting a web browser. 
> > >
> > > do you have something like:
> > >
> > > application/pdf;        xpdf '%s';      prioryty=1;     test=test -n "$DISPLAY"
> > >
> > > in ~/.mailcap or /etc/mailcap? 
> >
> > No I did not.
> >
> > > If not, can you add it to ~/.mailcap and check
> > > xdg-open again?
> > >
> > > You can also add to ~/.mime.types:
> >
> > I have no such file
>
> create it then
>
> > > application/pdf           pdf
> >
> > (didn't try adding any .mime.types file. Are you sure it isn't "xpdf" at 
> > the end?)
>
> yes, I'm sure (it will let xdg-open know that *.pdf files have
> application/pdf mime type and later it will choose the right app from
> ~/.mailcap)
>
> > > if /etc/mime.types doesn't have it.
> >
> > No such file in /etc, either.
>
> so that's why xdg-open tries to open this file in a browser
>
> > The man page says it has something to do 
> > with cups.
>
> nothing to do with CUPS, see http://en.wikipedia.org/wiki/Mailcap
>
> > No help from adding the line to .mailcap.
>
> echo 'application/pdf pdf' >> ~/.mime.types


OK. I can not do any more of this on the machine which is in the workplace 
right now, but I tried it at home on my Raspberry Pi which was having the 
same problem. It seems to fix the problem well enough.

Some observations, both for you who apparently are connected with xdg-open 
and for the MC people:

1. The RPI is a little machine, with minimal resources. It is not expected 
to deal with mail, so there was no .mailcap file. No mail programs, not 
even client programs, and so nothing related was installed, either. Hence, 
the only way that was reasonable for creating a .mailcap file was to copy 
one over there. For similar reasons, there was no /etc/mime.types, either, 
and no .mime.types file in my user directory.

2. MC is supposed to be a comparatively light file manager which will do 
all kinds of good stuff whether one is in a terminal or in an xterm. In 
the past it has pretty much been that way. But now there is a string of 
really weird dependencies, it seems. And no obvious documentation for 
those dependencies. I mean, all of a sudden it seems I am supposed to be 
running a mail server, or something similar, in order to have on hand some 
some stuff without which things do not work right, and quite unexpectedly 
and inexplicably.

3. The machine in the office is an actual mail server and internet host. 
It has been running and doing its job for years; with occasional need for 
replacing failing hardware and with occasional software and OS upgrades it 
has run for well over a decade. There was no /etc/mime.types or 
$HOME$/.mime.types file on it, either. And the lack of that file has never 
until now caused any trouble or complaint.

3. I can see why MC wants to use a general-purpose open-the-file 
arrangement. The logical branches in the extension file _were_ getting 
unwieldy. But how about providing things like needed configuration files 
in an installation package instead of making hidden assumptions about what 
is on "everybody's" machine?

4. I would say similar things to the developers of xdg-open. Why is it 
depending on things which might not necessarily be present on someone's 
installation? Why is as it difficult as it seems to me to be, to learn 
exactly what xdg-open is doing? It would be really nice if it were clearly 
stated in the man page, or in some info on line somewhere, exactly what 
steps that xdg-open takes in order to decide what to do with whatever kind 
of file, and perhaps a few words about why it was done that way, too. But, 
no, it seems again to have been assumed that "everybody already has a 
(fill in the blank) and so we will just use it and not tell anybody." Also 
the decision that "when in doubt, open the web browser and make it do the 
work" seems to me a rather strange way to go, too. I mean, what happened 
to the use of an error message which tells the user what went wrong, 
instead of explaining nothing and just punting by opening a freaking web 
browser?

The free availability of the (missing or hard-to-get) information in item 
4 might well have avoided trouble all the way down the line. For 
certain, it would have made it unnnecessary for someone to send an 
e-mail to a public list, which might have been mistaken for a flame.

Anyway, thanks for being able to pinpoint the problem. I would never have 
guessed, in view of the fact that configuration files are needed which 
were never needed before for anything, and there does not seem to be any 
easy-to-find and clear explanation, either, about those hidden 
dependencides.

Theodore Kilgore