Funny action on "opening" a pdf document

Theodore Kilgore kilgota at banach.math.auburn.edu
Thu Jan 17 19:03:24 UTC 2013



On Fri, 18 Jan 2013, Slava Zanko wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 16.01.2013 17:55, Theodore Kilgore wrote:
> 
> Please, update to latest version (4.8.7) and try to run:
> MC_XDG_OPEN=false mc
> 
> It's will switch off the usage of xdg-open and will use an internal
> file associations.
> 
> Is it what you expected?

I expect that if I have to do this it will take a bit of time. Probably 
the first thing needed will be to fetch the new version. Remind me where I 
am supposed to get it. 


Also there is the question that why did this happen on the machine where 
it happened (and happened on my little RPI too) but did not happen on my 
main home machine where the same version of mc is being run. Clearly, it 
is a difference in the configuration. But what does that difference 
consist of? On the home machine (from which I am typing now) the Edit 
extension file option calls up a file which contains

type/^PDF
<------>Open=(xpdf %f &)
<------>#Open=(acroread %f &)
<------>#Open=(ghostview %f &)
<------>View=%view{ascii} pdftotext %f -

and on the office machine it says instead

# PDF
type/^PDF
<------>Open=/usr/libexec/mc/ext.d/doc.sh open pdf
<------>View=%view{ascii} /usr/libexec/mc/ext.d/doc.sh view pdf

Both machines have version 4.8.4. So I am not sure how to account for this 
difference. 

Now, as far as the RPI is concerned, it looks as though I did something by 
hand. It fixes _my_ problem but still leaves a question unanswered. What 
the file on the RPI said was identical to the above, but now it says 

# PDF
type/^PDF
#<------>Open=/usr/libexec/mc/ext.d/doc.sh open pdf
<------>Open=/usr/bin xpdf
<------>View=%view{ascii} /usr/libexec/mc/ext.d/doc.sh view pdf

and the problem went away because I hit it with a hammer.

Finally, you say to install the newest version of mc, and then to run 
"MC_XDG_OPEN=false mc" which I would judge means "don't use xdg_open." In 
other words, I am not sure this leads to a decisive solution if one would 
occasionally like to use xdg-open for something. I myself have never used 
it for anything before, and I have never felt particularly inconvenienced. 
But I can see that others might want to. So ...


A better question is exactly why xdg-open is doing this kind of nonsense 
in the first place. The man page of xdg-open points a finger of suspicion 
at it, in that it mentions the ability to "open" such a thing as a URL by 
firing up the browser and going to the appropriate URL. And I have 
tried that now to see if it works, and indeed it does. If you type at 
the command line in an xterm "xdg-open ftp://ftp.slackware.com" it 
starts firefox and goes to ftp://ftp.slackware.com. But the man page 
says that xdg-open will do even more. The man page starts by saying

"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. 

This led me to try testing out xdg-open all by itself, quite independently 
of mc. So, what I did was to open an xterm. I have a file called MATH.pdf" 
and so I did

xdg-open MATH.pdf

and it opened the file with xpdf well enough, and moreover it opened 
another, perfectly blank tab in firefox (which was also open at the time). 
Trying this again with firefox closed, it opened the file with xpdf and 
also managed for no good reason and contrary to its advertised behavior, 
to fire up an empty, blank session of firefox.

I suspect that the problem is, you trusted xdg-open to do what the man 
page says it will do, instead of seeing what it actually does. For, the 
evidence leads one to conclude that the responsible factor for the problem 
is either a bug in xdg-open (it isn't doing what its own man page says it 
will do), or it is a problem in the config settings of xdg-open (because 
it doesn't do what its own man page says it will do). At this point I am 
not sure which one of these two it is. But in either event the problem is 
obviously not going to be solved by an upgrade to a newer version of mc, 
unless you have either quit using xdg-open for certain purposes until they 
fix their obvious bug, or they have fixed their obvious bug. From that 
point of view it does not matter whether their obvious bug is in the code 
or in the config settings.

Thus, my next step will probably be to find some more information about 
xdg-open. 

Theodore Kilgore

> 
> - -- 
> WBR, Slavaz.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> 
> iEYEARECAAYFAlD4c0EACgkQb3oGR6aVLppzPgCfSGSqdT3Vs1OMGg2F36/1roWj
> SOsAnRVv93j3dX/9kNOAN3aPtd9z09nm
> =MxFn
> -----END PGP SIGNATURE-----
> _______________________________________________
> mc mailing list
> https://mail.gnome.org/mailman/listinfo/mc
> 



More information about the mc mailing list