mimeo: open files by mimetype or file name

Ram-Z · 2013-08-26 06:32:06

Thanks, both commands work like a charm.

likytau · 2014-02-22 07:31:28

I'm currently working on something that could use Mimeo to good effect. However, I haven't been able to determine clearly how to get mimeo to block until all launched applications have terminated. Is this currently possible?

The script in question is here (apps used for opening are currently hardcoded)

Xyne · 2014-02-22 11:38:24

You can use the "-c" option to collect the commands and then run them synchronously with the subprocess module. I was going to suggest using the Mimeo module directly but unfortunately it is still written in Python 2. Rewriting it in Python 3 has been on my agenda for a while but it is very far down on the list and I have no time for it.

likytau · 2014-02-22 13:52:12

^ thanks, that will work (the script is compatible with both py2 and 3, so I can run it with whatever)

2to3 suggests that with minor changes, so can mimeo be. Its suggested diff is here.

EDIT:
Although the fact that get_cmds returns a list of strings, and not a list of lists of strings, is disturbing and potentially insecure. I can use it okay, I just want to shoot it until it is dead, and then a bit more for good measure.

Last edited by likytau (2014-02-23 01:36:52)

Xyne · 2014-02-23 12:48:43

Getting the current code to run with Python 3 would not be difficult, but I plan to use the opportunity to refactor most of the code. A lot of it was cobbled together from bits and pieces that I had written for other tasks and the overall design requires an overhaul.

As for the commands being passed as single strings instead of a list of strings, that is how they are represented in the desktop files themselves. Breaking them up requires shell parsing no matter how you do it. In the rewrite I may very well include that in the parser and return the list, but all that really does is hide the potential insecurity that you mention.

progandy · 2014-02-23 13:00:54

Xyne wrote:

As for the commands being passed as single strings instead of a list of strings, that is how they are represented in the desktop files themselves. Breaking them up requires shell parsing no matter how you do it. In the rewrite I may very well include that in the parser and return the list, but all that really does is hide the potential insecurity that you mention.

Python has that nice shlex module you might use.

Getting the current code to run with Python 3 would not be difficult, but I plan to use the opportunity to refactor most of the code. A lot of it was cobbled together from bits and pieces that I had written for other tasks and the overall design requires an overhaul.

Sometimes I miss an option to specify a file and the .desktop file which should be used to open it and/or a menu with all possible choices and not just the default entry (just like "open with" in graphical file managers).

Last edited by progandy (2014-02-23 13:01:24)

Gamonics · 2015-02-13 16:41:12

Xyne wrote:

Getting the current code to run with Python 3 would not be difficult, but I plan to use the opportunity to refactor most of the code. A lot of it was cobbled together from bits and pieces that I had written for other tasks and the overall design requires an overhaul.
...
In the rewrite I may very well include that in the parser and return the list, but all that really does is hide the potential insecurity that you mention.

I learned about mimeo in the wiki ("If you run xdg-open without a desktop environment, you should also install perl-file-mimeinfo, or xdg-utils-mimeo and mimeo from the AUR for a faster alternative. "). I'm experimenting with i3wm, so I guess that's me (running xdg-open without a DE), but xdg-utils got pulled in as a dependency for loads of other packages I installed with pacman, so I'm a bit hesitant to just up and replace it before understanding more about what it does and how mimeo replaces it.

Has the overhaul/rewrite mentioned here been done yet? I saw updates in AUR from 10/14, but don't understand what changed from the time of this post above. Does the current code run with Python 3? What's general consensus on the currency & functionality of xdg-utils-mimeo/mimeo as compared with xdg-utils? Speed is not a critical concern for me; I just want to know if mimeo accomplishes everything that xdg-utils does. And if so, does it do it better? And how so?

Alad · 2015-02-14 22:07:13

First just for the record, mimeo can't, in itself, replace xdg-utils. You could symlink it to xdg-open in /usr/local, but some obstinate programs (like Chromium) hardcode the xdg-open path, and there's stuff like xdg-email. There's however xdg-utils-mimeo as suggested in the wiki.

Has the overhaul/rewrite mentioned here been done yet?

Not that I know of, but bugs get fixed quickly. That's something you can't say of projects like xdg-utils or mimeinfo. Even if speed is not critical to you, waiting dozens of seconds for programs should still be annoying. mimeinfo doesn't appear to fork relevant programs also, which is annoying in programs like Midnight Commander (though see this post).

Does the current code run with Python 3?

I'm not sure why this should be a great concern, but it appears to rely on python2.

And if so, does it do it better?

I'd suggest you to read the help files for both programs. You'll see mimeo is a lot more flexible than xdg-open/mimeinfo.

Xyne · 2015-02-23 20:03:22

Recent updates were for bug fixes. I would still like to refactor the code in Python 3 but due to the combination of limited time and low priority it just hasn't happened yet.

As for how it compares to e.g. xdg-open, I really can't say as I only use mimeo. Read the documentation and try them both to see which one does what you want the best.

Xyne · 2016-01-13 01:44:37

Ok, Mimeo has been completely rewritten in Python 3 with (what should be) adherence to the latest version of the standard on freedesktop.org.

Mimeo.py header wrote:

'''
Mimeo *should* follow the latest version of the specifications found on the
freedesktop.org site:

    http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html
    http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
    http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
    http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

Internally Mimeo uses pyxdg:

    http://freedesktop.org/wiki/Software/pyxdg/
    http://pyxdg.readthedocs.org/en/latest/index.html

'''

As with any rewrite, there are likely some bugs. They should be easy to fix now given that the code base is no longer a shining, shameful beacon of kludges and noobishness. Let me know what works and what doesn't.

NB! To use files in the now-deprecated $XDG_DATA_HOME/applications directory (~/.local/share/applications by default), you must use the --deprecated flag. See the changelog for further information.

Some informational output formats have changed as well. I'll add that to the changelog for the next mini-release.

xduugu · 2016-01-13 18:26:22

Hi Xyne,

thanks for the rewrite. It works great!

Some notes and possible improvements:

cosmetic: add an empty line before each section (which is not in the first line of the file) in mimeapps.list.
An empty line before "[Added Associations]" makes it easier for the eye to parse the file.
the default associations file is not taken into account
I moved the old mimeo.conf file to the new location ($HOME/.config/mimeo/associations.txt) as printed in "mimeo --help", but it has no effect. When I add "-a $HOME/.config/mimeo/associations.txt" to the mimeo call, it works though.
Is there a way to tell mimeo to use all specified mime types of a desktop file for the current opperations?
I would like to do something like "mimeo --prefer firefox.desktop" ("prefer firefox for all mime types it claims to support") which should add all the listed mime types from the firefox.desktop file to the "Default Applications" section. It should result in something like that:
```
[Default Applications]
text/html=firefox.desktop;
text/xml=firefox.desktop;
application/xhtml+xml=firefox.desktop;
application/vnd.mozilla.xul+xml=firefox.desktop;
text/mml=firefox.desktop;
x-scheme-handler/http=firefox.desktop;
x-scheme-handler/https=firefox.desktop;
x-scheme-handler/ftp=firefox.desktop;
```

Xyne · 2016-01-14 00:34:54

I noticed the associations file bug earlier today and fixed it.
Empty lines should now be inserted between sections in mimeapps.list files.
All of the association modifiers will now collect MIME-types from the desktop files if no MIME-type matcher is given. Note that the MIME-types are pooled though, so "mimeo --prefer firefox.desktop" will do what you expect but "mimeo --prefer firefox.desktop medit.desktop" will make firefox and medit the preferred applications for all of firefox's MIME-types and all of medit's MIME-types.

While implementing that I fixed some other things and ended up with more operations: --desk2mime, --mime2desk

Thanks for the feedback!

xduugu · 2016-01-14 19:52:10

Opening files is broken for me since version 2016.1.13.4, which added this section in function desktop_entry:

  if none_if_error:
    try:
      # This will raise ParsingError if the file is not found.
      de.parse(path)
    except (
      xdg.DesktopEntry.ParsingError,
      xdg.DesktopEntry.DuplicateGroupError,
      xdg.DesktopEntry.DuplicateKeyError
    ) as e:
      logging.debug('error loading {}: {}'.format(path, e))
      return None
  else:
    de.parse(path)

I'm not sure if this is a bug in mimeo or a faulty file on my side. It happens for every file, not just the one in the example.

$ mimeo install.pdf 
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/xdg/IniFile.py", line 77, in parse
    key, value = line.split("=", 1)
ValueError: not enough values to unpack (expected 2, got 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/Mimeo.py", line 743, in desktop_entry
    de.parse(path)
  File "/usr/lib/python3.5/site-packages/xdg/DesktopEntry.py", line 42, in parse
    IniFile.parse(self, file, ["Desktop Entry", "KDE Desktop Entry"])
  File "/usr/lib/python3.5/site-packages/xdg/IniFile.py", line 79, in parse
    raise ParsingError("Invalid line: " + line, filename)
xdg.Exceptions.ParsingError: ParsingError in file 'install.pdf', Invalid line: %PDF-1.4

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.5/site-packages/Mimeo.py", line 1932, in <module>
    main()
  File "/usr/lib/python3.5/site-packages/Mimeo.py", line 1923, in main
    for c in mimeo.args_to_cmds(pargs.args, fallback=True):
  File "/usr/lib/python3.5/site-packages/Mimeo.py", line 1301, in args_to_cmds
    de = desktop_entry(d, none_if_error=True)
  File "/usr/lib/python3.5/site-packages/Mimeo.py", line 746, in desktop_entry
    xdg.DesktopEntry.DuplicateGroupError,
AttributeError: module 'xdg.DesktopEntry' has no attribute 'DuplicateGroupError'

Xyne · 2016-01-14 20:30:02

Sorry about that. I noticed it earlier today but couldn't upgrade. I mixed up the items of a 2-tuple when making the previous changes. It should be fixed now. I have made some other changes too

Thanks for all the feedback.

Alad · 2016-01-16 15:52:39

Great work

One thing I've noticed, if you have a file:///... argument to an html file, and a # is passed for an article section, e.g:

mimeo  'file:///usr/share/recoll/doc/usermanual.html#RCLINDEXING'

it fails with:

WARNING: failed to determine command for file:///usr/share/recoll/doc/usermanual.html#RCLINDEXING

Xyne · 2016-01-16 18:39:55

File URLs should be handled correctly now. You can even use 'file://localhost/path/to/foo#whatever' now.

Alad · 2016-01-16 21:32:48

Works as expected, cheers Xyne.

xduugu · 2016-01-20 13:30:15

Using mimeo 2016.1.18.2-1, it starts more than one program (actually two) for a given file for me, but I'm not sure if this issue was introduced in this version.
I use "--by-content-first" as default argument and only one desktop file is listed in the "Default Applications" section for this mimetype. (Actually, I don't know if it is allowed to have more than one desktop file listed as default application for a mimetype, but it is possible with mimeo).

xduugu · 2016-01-20 13:42:01

The issue seems to be in to mimetype detection part. When mimeo is not called with a "--by-*-only" option, it returns two mimetypes for me. One from the content detection and one from the name.

$ mimeo -m a.mkv 
a.mkv
  application/x-matroska
  video/x-matroska
$ mimeo -m --by-content-only a.mkv 
a.mkv
  application/x-matroska
$ mimeo -m --by-content-first a.mkv 
a.mkv
  application/x-matroska
  video/x-matroska
$ mimeo -m --by-name-only a.mkv 
a.mkv
  video/x-matroska

bashnev · 2016-01-20 13:43:24

I found that xdg-open from xdg-utils-mimeo fails to open a file if it has spaces in its name. The xdg-open in extra works.

Alad · 2016-01-20 16:08:47

bashnev wrote:

I found that xdg-open from xdg-utils-mimeo fails to open a file if it has spaces in its name. The xdg-open in extra works.

Does it work if you run mimeo directly on the file? With quotes, of course.

Last edited by Alad (2016-01-20 16:08:58)

Xyne · 2016-01-20 22:01:53

@xduugu
The --command option prints the commands that it would run otherwise. That part of the code basically looks like this : if "--command" print it else run it, so it will always run the exact commands that would have been run (unless the new "--show-all" option is passed).

Anyway, it should be fixed now, along with ordering of preferred applications/desktops. Check the changelog for more info. Thanks again for reporting.

@bashnev
I believe that mimeo correctly handles all input arguments as single words. Please test it using mimeo directly as Alad has suggested. If that works then the error lies with xdg-utils-mimeo. I am not involved in that project so you will need to report the error to the developer.

xduugu · 2016-01-20 23:05:48

The --command option listed two commands without the show-all option before. It works now, but the --mimetype option may still list more than one mimetype for a single file, which is a quite unexpected behavior to me. Since only the first listed mimetype seems to be relevant, I would expect that only this one is printed.

Apart from the previous issues, mimeo is way better than the python2 version now. Thanks a lot.

eschwartz · 2016-01-21 00:35:19

Xyne -- see https://bbs.archlinux.org/viewtopic.php?id=207758 where this came up.

xdg-utils-mimeo simply runs

mimeo "file:///tmp/name%20with%20space.txt"

Which tries to open a file named name%20with%20space.txt -- instead of urldecoding it.
Needless to say every other xdg-utils file handler correctly urldecodes things (and failure to do so has historically been treated as a bug in the file handler rather than xdg-utils)... so this is definitely mimeo's fault.

Last edited by eschwartz (2016-01-21 00:36:04)

Xyne · 2016-01-21 03:25:25

@xduugu
The query operations (--mimetype, --desktop) will now print one result per argument unless the --show-all operation is given. I have also added a --swap option to swap the way the results are displayed.

@Eschwartz
"%20" may represent a space, but it isn't a space, so the error report that mimeo fails to open a file because the file "has spaces in its name" was misleading. Anyway, I have added percent-decoding where necessary so it should now work like "every other xdg-utils file handler"

Arch Linux

#101 2013-08-26 06:32:06

Re: mimeo: open files by mimetype or file name

#102 2014-02-22 07:31:28

Re: mimeo: open files by mimetype or file name

#103 2014-02-22 11:38:24

Re: mimeo: open files by mimetype or file name

#104 2014-02-22 13:52:12

Re: mimeo: open files by mimetype or file name

#105 2014-02-23 12:48:43

Re: mimeo: open files by mimetype or file name

#106 2014-02-23 13:00:54

Re: mimeo: open files by mimetype or file name

#107 2015-02-13 16:41:12

Re: mimeo: open files by mimetype or file name

#108 2015-02-14 22:07:13

Re: mimeo: open files by mimetype or file name

#109 2015-02-23 20:03:22

Re: mimeo: open files by mimetype or file name

#110 2016-01-13 01:44:37

Re: mimeo: open files by mimetype or file name

#111 2016-01-13 18:26:22

Re: mimeo: open files by mimetype or file name

#112 2016-01-14 00:34:54

Re: mimeo: open files by mimetype or file name

#113 2016-01-14 19:52:10

Re: mimeo: open files by mimetype or file name

#114 2016-01-14 20:30:02

Re: mimeo: open files by mimetype or file name

#115 2016-01-16 15:52:39

Re: mimeo: open files by mimetype or file name

#116 2016-01-16 18:39:55

Re: mimeo: open files by mimetype or file name

#117 2016-01-16 21:32:48

Re: mimeo: open files by mimetype or file name

#118 2016-01-20 13:30:15

Re: mimeo: open files by mimetype or file name

#119 2016-01-20 13:42:01

Re: mimeo: open files by mimetype or file name

#120 2016-01-20 13:43:24

Re: mimeo: open files by mimetype or file name

#121 2016-01-20 16:08:47

Re: mimeo: open files by mimetype or file name

#122 2016-01-20 22:01:53

Re: mimeo: open files by mimetype or file name

#123 2016-01-20 23:05:48

Re: mimeo: open files by mimetype or file name

#124 2016-01-21 00:35:19

Re: mimeo: open files by mimetype or file name

#125 2016-01-21 03:25:25

Re: mimeo: open files by mimetype or file name

Board footer