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 _______________________________________________ mc mailing list https://mail.gnome.org/mailman/listinfo/mc