Created attachment 657209 [details] Example MS Mac Excel file Description of problem: When exo-open is given a "Microsoft Macintosh Excel" file (as identified by 'file'), it will correctly launch LibreOffice only if the filename has extension .xls or .xlsx. If the filename has extension '.bin', exo-open incorrectly selects epdfview, which exits with error status. Version-Release number of selected component (if applicable): exo-0.6.2-4.fc17.x86_64 How reproducible: Not sure. I have limited test cases. Steps to Reproduce: 1. Get MS Excel file produced on Apple Mac PC 2. copy file to name.bin and name.xls 3. try to open with 'exo-open <filename>' Actual results: 1. 'exo-open file.bin' tries to pass file to epdfview & fails with error exit code 2. 'exo-open file.xls' chooses LibreOffice Calc & succeeds Expected results: exo-open should select the same program regardless of filename and should choose LibreOffice Calc for MS Excel files. Additional info: xdg-open identifies the file type correctly regardless of name, but then it launches exo-open instead of launching the application itself. I wish I understood how that is configured.
This is based on mime type. ;) % mimetype foo foo: application/x-ole-storage % mimetype foo.bin foo.bin: application/octet-stream % mimetype foo.xls foo.xls: application/vnd.ms-excel So, when it's 'foo.bin' it gets a generic binary type. You can make exo-open do something else on that if you like. In Xfce 4.10 (fedora 18) theres a xfce4-mime-editor. In f17 you can use xdg-mime: xdg-mime default /usr/share/applications/libreoffice-calc.desktop application/octet-stream Or just right click on the file in Thunar and say "open with other application" I'm not sure thats great, as that will open any binary in calc... I don't know that there's any better solution for you here.
Again, thanks so much for your help. I'm sorry for the trouble. It sounds like this is not a bug and exo is working as expected. But, now I'm very confused. 1) I know what MIME types are, but where is the program 'mimetype' ? It sounds vaguely familiar from many years ago, but I cannot find it anymore: > yum search mimetype Loaded plugins: changelog, langpacks, presto, refresh-packagekit, remove-with-leaves, show-leaves ======================================= Matched: mimetype ======================================= python-relatorio.noarch : A templating library able to output odt and pdf files 2) I *thought* the way to ask xdg what is the MIME type of a file was this command: > xdg-mime query filetype octet-stream.bin application/vnd.ms-excel 3) So, I *think* xdg (correctly) identifies the filetype by content and isn't confused by the name. If that's true, there isn't any need to change the MIME-type-to-application association. The problem seems to occur when xdg hands the file to exo, which doesn't come to the same conclusion as xdg about the type of file it has been handed. 3a) Is it possible to get exo to use the same method as xdg to determine the MIME type of the file? Presumably, this would result in the desired outcome. 3b) Is it possible to tell xdg *not* to hand the file to exo? (I tried, but xdg seems to ignore the environment variable the man page says controls the type of desktop xdg thinks is running. Or, I don't understand how xdg works, which is quite clearly true.)
mimetype is in perl-File-MimeInfo package. I'm not fully sure about your questions in part 3, I'll do some digging around... :)
I had a quick sec to check and this is still present in F18.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
exo-open still cannot open this file in F19, error code 130. In F19, exo-open doesn't appear to launch any application. When I reported this, I said it tried to pass the file to epdfview. I don't remember how I new that, but now, at least, I can't see any application is started. On the other hand, xdg-open can't open the file either, but now it's not handing the file to exo. This is a new complication. I'm so glad this is getting worse, not better, as time goes forward. xdg-open now passes many (but not all) files to Firefox, including application/vnd.excel files, apparently. This is new behavior and also incorrect. But, the fact remains, exo cannot open this file even though the type is correctly identified and suitable programs are installed.
Well, if you go run xfce4-mime-settings and set libreoffice as the application for application/octet-stream I would expect exo-open to work. Of course then _other_ stuff thats not excel will get opened by it too, but perhaps this is a good enough workaround?
Okay. I guess there is not way to get exo-open to take advantage of xdg-open's superior filetype detection. I'm guess I'm more upset that, if I ask xdg to do everything itself, which seems like the obvious solution, it passes all files to firefox even though filetype associations are correct. I'll start looking at xdg for a fix. Barking up the wrong tree, I think. Thanks.
Well, I think I've been misled. I've been reading about it, and I get the feeling that xdg-open is working as designed. That is, it was never intended that xdg-open could open anything by itself. I think your original suggestion is probably the best option, for now. I don't know how it detects file mimetypes, but, whatever it is, it is superior to that used by exo and the 'mimetype' PERL script. It would be really really great if exo could be improved in this way. Side Note: Why is 'file' so much better? Or, equivalently, why cannot the 'file' code be used in some way by exo- and others? It's so much more accurate than every other tool. It's been around for decades and I can only remember one time when it let me down. It's legendary.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.