Funny action on "opening" a pdf document
Theodore Kilgore
kilgota at banach.math.auburn.edu
Sat Jan 19 18:03:16 UTC 2013
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
More information about the mc
mailing list