Package Details: mimeo 2016.2-1

Git Clone URL: https://aur.archlinux.org/mimeo.git (read-only)
Package Base: mimeo
Description: Open files by MIME-type or file name using regular expressions.
Upstream URL: http://xyne.archlinux.ca/projects/mimeo
Keywords: utilities
Licenses: GPL
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 112
Popularity: 0.942982
First Submitted: 2009-12-16 02:54
Last Updated: 2016-02-10 20:29

Dependencies (4)

Required by (3)

Sources (2)

Latest Comments

zoopp commented on 2016-01-25 19:13

I'm experiencing a weird issue in which mimeo launches two applications when I want to open certain files.

For example,
┌─┤21:07:19│zoopp@zoopp-laptop:~
└──────────╼ mimeo --debug ~/wallhaven-317663.jpg
DEBUG: loading arguments from /home/zoopp/.config/mimeo/default_arguments.txt
DEBUG: opening /home/zoopp/.config/mimeo/associations.txt
DEBUG: ['/usr/bin/eog', '/home/zoopp/wallhaven-317663.jpg']
DEBUG: ['gimp-2.8', 'file:///home/zoopp/wallhaven-317663.jpg']

I've noticed that this happens only for files which have associations in ~/.config/mimeo/associations.txt. For reference, these are the file contents: https://paste.kde.org/po6wbvc9i.

I'm thinking of taking a look into it when I'll get some time. In the meantime, might someone have any ideas what could be wrong?

xduugu commented on 2016-01-13 18:05

Thanks a lot for the fast fix/rewrite.

Xyne commented on 2016-01-13 01:37

I have completely rewritten Mimeo in Python 3 while trying to adhere to the current standard on freedesktop.org.

Please use the forum thread[1] to report Mimeo errors and give feedback to keep the discussion in one place.

[1] https://bbs.archlinux.org/viewtopic.php?id=86855

Xyne commented on 2016-01-10 08:07

@xduugu
The specification has changed a bit since Mimeo was written. Kludging in the new changes to the current messy codebase would be error-prone. I have been meaning to overhaul and rewrite it in Python 3 for years and with this I have finally started. I don't know how long it will take though, but I will post an update as soon as I have the time to finish it.

xduugu commented on 2016-01-06 17:59

Hi Xyne,

according to [1], the default location of the mimeapps.list file is $XDG_CONFIG_HOME/mimeapps.list and $XDG_DATA_HOME/applications/mimeapps.list is deprecated and only kept for compatibility.
The specification also says that the default applications are stored in the mimeapps.list file as well. A default.list file is not mentioned in the specification.
Could you adjust mimeo to comply with the specification? Thanks a lot!

[1] http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html

xduugu commented on 2015-06-23 08:46

> @xduugu
> I have added a "--by-content" option to bypass the filename check. Please test > it and let me know if it works as expected.

(Copied your answer from the old AUR)

It works as expected. Thanks a lot.

xduugu commented on 2015-06-22 09:56

Hi Xyne, thanks for mimeo. It's a great replacement for xdg-open. There is only one feature I'm missing:

Would it be possible to introduce an additional commandline option to bypass the file extension check in line 755:

mimetype = mimetypes.guess_type(rpath)[0]

and always rely on the file utility instead? Similar to mimeopen's option:

-M, --magic-only
Do not check for extensions, globs or inode type, only look at the
content of the file. This is particularly useful if for some reason
you don't trust the name or the extension a file has.

mladoux commented on 2015-05-23 04:09

Fix typo from pazpi's comment. yes it does work.

gpg --recv-keys 1D1F0DC78F173680

pazpi commented on 2015-03-29 19:45

To verify your gpg key, just run gpg --rev-keys 1D1F0DC78F173680.
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

nfisher1226 commented on 2015-02-23 01:30

Never mind, I answered my own question by reading the docs more thoroughly. My solution involved doing some configuration for gpg so that it retrieves the keys. A wiki edit might be in order to make it easier to find the solution for those who don't use gpg regularly.

nfisher1226 commented on 2015-02-15 18:01

Source verification is failing (unknown public key. In a bid to force it through I disabled the sig in the PKGBUILD but then it fails with a bad md5sum.

Xyne commented on 2015-01-15 06:30

@Alad
When looking through the code today I noticed that preferences are already added to the both the defaults.list file and the "Default Applications" group of the mimeapps.list file. They are also read from both files, in that order. Mimeo should therefore already be compatible with xdg-mime.

I have updated Mimeo to import preferences in defaults.list into the group in mimeapps.list. Running "mimeo --update" should do this.

I recommend against using the suggested symlink trick.

If you still don't get compatible behavior, please give me a reproducible example so that I can determine what is wrong.

Alad commented on 2015-01-10 13:14

Until you have some more time, maybe someone will find this workaround useful:

$ ln -s ~/.local/share/applications/mimeapps.list ~/.local/share/applications/defaults.list

Alad commented on 2014-12-31 04:44

http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html

Xyne commented on 2014-12-31 01:17

The default.list file was part of the specification when I wrote Mimeo. If you can show me an updated specification then I will change it, but I'm a bit short on time right now so I don't want to go digging for it.

Alad commented on 2014-12-30 22:11

Found something interesting: mimeo writes the preference to ~/.local/share/applications/defaults.list, while xdg-mime does so to ~/.local/share/applications/mimeapps.list.

Alad commented on 2014-12-29 19:49

Sorry for the belated reply. Running

mimeo --prefer application/pdf kde4-okularApplication_pdf.desktop

gives the expected results. As to active-documentviewer_pdf.desktop, ironically that's part of the Okular package (kdegraphics-okular) - even when that package lacks the active-documentviewer binary.

Happy new year

Xyne commented on 2014-12-10 01:10

@Alad
Try setting the preferred association of application/pdf to kde4-okularApplication_pdf.desktop. I would also investigate why kde4-active-documentviewer_pdf.desktop refers to an apparently inexistent application in its Exec field. Where did that file come from?

Alad commented on 2014-12-05 21:47

Sure:

archie@thinkpad ~ % mimeo -m .pdf
LA1_141128.pdf
application/pdf
archie@thinkpad ~ % mimeo -d .pdf
LA1_141128.pdf
kde4-active-documentviewer_pdf.desktop /usr/share/applications/kde4/active-documentviewer_pdf.desktop
kde4-okularApplication_pdf.desktop /usr/share/applications/kde4/okularApplication_pdf.desktop

Xyne commented on 2014-12-04 22:17

I still don't understand why it's trying to launch something named "active-documentviewer". Would you please run "mimeo -m .pdf" and "mimeo -d .pdf" to determine mimetype and desktop files detected by mimeo (which may be different from xdg-mime)?

Alad commented on 2014-12-01 19:14

Thanks for the update btw.

Alad commented on 2014-12-01 06:54

Well I've taken a closer look at the okular desktop file (/usr/share/applications/kde4/okularApplication_pdf.desktop) and it had "NoDisplay=True" ... so mimeo tries to launch the next in line (documentviewer), which I don't have installed. Copying the desktop file and removing the NoDisplay line makes it work again.

Here's the log/file anyway:

http://pastie.org/9753450

Xyne commented on 2014-11-30 16:49

@Alad
I've added code to catch the OSError in this case but the real problem is either an error in the okular desktop file or an error in Mimeo's parsing of it. Please update to the latest version of Mimeo and post the full error message along with the okular desktop file.

Alad commented on 2014-11-30 13:10

Having a similar issue:

http://pastebin.com/R9y4y2K1

PDF assocation was set with "xdg-mime default okular.desktop application/pdf". Running "mimeo --purge delete" didn't help (with or without new association set)

Xyne commented on 2014-11-25 00:09

@nunopcardoso
Thanks for notifying me of the problem and posting a fix. Given that the expected behavior is to print nothing when no associated desktop files are found, I have implemented my own solution using a try-except block. I'm assuming that the error was a KeyError.

I suspect that this was caused by outdated associations in your local MIME files. Mimeo's --purge function should be able to fix this.

Please pastebin code output next time (or email it directly to me). Posting code chunks in AUR comments is against our policy (usually due to formatting, sometimes due to size).

Regards,
Xyne

nunopcardoso commented on 2014-11-24 12:36

I was getting the following error when using the -d flag on a file for which the app list had unknown .desktop files:

$ mimeo -m $FILE
audio/mpeg
$ cat ~/.local/share/applications/mimeapps.list
[Default Applications]
audio/mpeg=asda;
$ mimeo -d $FILE
Traceback (most recent call last):
File "/sbin/mimeo", line 6, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2181, in main
rows.append((name, names[name]))



After fix:

$ mimeo -d $FILE
asda <Not found>
$ diff /usr/lib/python2.7/site-packages/Mimeo.py Mimeo.py -Naur
--- /usr/lib/python2.7/site-packages/Mimeo.py 2013-07-24 21:47:05.000000000 +0100
+++ Mimeo.py 2014-11-24 12:19:43.065298745 +0000
@@ -2178,7 +2178,10 @@
mimetype = mimeo.get_mimetype(arg)
if mimetype:
for name in mimeo.get_associated_desktop_names(mimetype):
- rows.append((name, names[name]))
+ if name in names:
+ rows.append((name, names[name]))
+ else:
+ rows.append((name, "<Not found>"))
table[arg] = rows
print table
mimeo.exit()

Xyne commented on 2014-05-17 11:57

@mrueegg
The message indicates that you have not installed my key. You can get it from my site, from the pacman keyring or from the MIT PGP keyserver. If you don't want to install it then you can ignore the warning.

mrueegg commented on 2014-05-14 15:19

Signature verification failed:

mimeo-2013.7.24.tar.xz ... FAILED (unknown public key 5CED81B7C2E5C0D2)
==> WARNING: Warnings have occurred while verifying the signatures.
Please make sure you really trust them.

Xyne commented on 2013-02-12 17:01

Mimeo 2013.2 uses defaults when the expected environment variables are not set.

xduugu commented on 2013-02-10 12:31

mimeo is currently broken when using testing (libx11-1.5.0-2) due to the removal of the XDG_CONFIG_HOME environment variable (https://bugs.archlinux.org/task/31204). I guess a fallback to $HOME/.config is needed.

Xyne commented on 2013-01-11 00:12

Have you tried mimeo's "--purge" option? If so, tell me what you think it should be doing instead.

antihero commented on 2013-01-08 12:37

That's done the trick.

Is there any way that mimeo can purge things from ~/.local/share/applications/mimeapps.list ? I had to spend ages with the mimeo code open printing stuff 'till I realised that was what was causing my associations to not change.

Xyne commented on 2012-11-23 13:54

@antihero
Let me know if the new release solves the problem. The error was caused by a broken desktop file so the purge should detect it.

antihero commented on 2012-11-22 13:11

Hmm, patch doesn't seem to fix *everything* though :(

antihero commented on 2012-11-22 13:08

Here's a patch:

https://gist.github.com/4131102

antihero commented on 2012-11-22 13:08

Here's a patch for previous issue.

--- Mimeo.py.old 2012-11-22 13:05:48.340854666 +0000
+++ Mimeo.py 2012-11-22 13:06:13.363724740 +0000
@@ -1219,6 +1219,10 @@
try:
desktop.load()

+ # Skip this desktop if it has no Desktop Entry Group
+ if not DEG in desktop:
+ continue
+
except IOError as e:
self.ioerror_msg(fpath, e, True)
del desktops[basename]

antihero commented on 2012-11-22 12:50

I'm getting this when I try to add/update/prefer anything:

Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2110, in main
mimeo.purge('nothing')
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1228, in purge
if desktop[DEG]['Hidden']:
KeyError: 'Desktop Entry'

uke-eda commented on 2012-10-24 06:29

On 24 Oct 08:27 no signature file at
http://xyne.archlinux.ca/projects/mimeo/archives/mimeo-2012.9.tar.xz.sig

xduugu commented on 2012-10-23 09:33

Please also update the checksums.

==> Validating source files with md5sums...
mimeo-2012.9.tar.xz ... Passed
mimeo-2012.9.tar.xz.sig ... FAILED
==> ERROR: One or more files did not pass the validity check!

Xyne commented on 2012-10-22 23:56

The signature should be valid now. I must have recreated the source archive.

Anonymous comment on 2012-10-22 17:08

Signature file is not available.

ninian commented on 2012-06-05 16:59

Thank you - all sounds very reasonable.

Experimenting a bit more with different ways of determining MIME-types throws up some farcical differences. For example, for a Firefox bookmarks.html file, 'file' shows "text/plain", 'rox' shows "text/html" and 'mimetype' shows "application/x-mozilla-bookmarks" on my system! Since I know little Python, I've done a patch which simply looks to see whether the environment variable $MIMEO contains one of 'file', 'mimetype' or 'rox' to determine the MIME-type (default is Python's mimetypes module). Also tweaked the help information to show this. Here's the patch: http://pastebin.com/6T5zFTsg

Just an idea, easier than adding options and changing a configuration file.

ninian commented on 2012-06-05 16:57

Sorry, forget that indentation will be lost when added as part of a comment. Here's the patch proper: http://pastebin.com/6T5zFTsg

ninian commented on 2012-06-05 16:52

Thank you - all sounds very reasonable. Experimenting a bit more with different ways of determining MIME-types throws up some farcical differences. For example, for a Firefox bookmarks.html file, 'file' shows "text/plain", 'rox' shows "text/html" and 'mimetype' shows "application/x-mozilla-bookmarks" on my system! Since I know little Python, I've done a patch which simply looks to see whether the environment variable $MIMEO contains one of 'file', 'mimetype' or 'rox' to determine the MIME-type (default is Python's mimetypes module). Also tweaked the help information to show this.
Here's the patch:

--- Mimeo.py 2012-06-02 15:26:00.000000000 +0100
+++ Mimeo_patched.py 2012-06-05 17:21:15.000000000 +0100
@@ -722,11 +722,23 @@ class Mimeo():
if os.path.isdir(rpath):
return DIRECTORY_MIMETYPE
elif os.path.isfile(rpath):
- mimetype = mimetypes.guess_type(rpath)[0]
- if not mimetype:
- proc = subprocess.Popen(['file', '--mime-type', rpath], stdout=subprocess.PIPE)
+ method = os.getenv("MIMEO")
+ if not method:
+ method = "python"
+ if 'file' in method:
+ proc = subprocess.Popen(['file', '--mime-type', rpath], stdout=subprocess.PIPE)
+ output = proc.communicate()[0]
+ mimetype = output[len(rpath)+2:].rstrip()
+ elif 'mimetype' in method:
+ proc = subprocess.Popen(['mimetype', '-i', rpath], stdout=subprocess.PIPE)
output = proc.communicate()[0]
mimetype = output[len(rpath)+2:].rstrip()
+ elif 'rox' in method:
+ proc = subprocess.Popen(['rox', '-m', rpath], stdout=subprocess.PIPE)
+ output = proc.communicate()[0]
+ mimetype = output[0:].rstrip()
+ else:
+ mimetype = mimetypes.guess_type(rpath)[0]
if not mimetype:
self.error_msg("error: failed to detect MIME-type of %s" % arg)
return mimetype
@@ -2026,7 +2038,7 @@ def main():



- conf_group = parser.add_argument_group('Configuration', 'Various configuration options.')
+ conf_group = parser.add_argument_group('Configuration', 'Various configuration options. Optionally, set the environment variable \'MIMEO\' to contain one of the following command names which will be used to determine MIME-types (assuming the relevant packages are installed): file, mimetype, rox. If none is specified, Python\'s \'mimetypes\' module is used instead.')
conf_group.add_argument('-a', '--assoc', dest='assoc', metavar='<filepath>', action='append',
help='Specify a file that associates regular expressions with custom commands. This can be used for opening URLs, for example. See "--assoc-help" for details.')

Just an idea, easier than adding options and changing a configuration file.

Xyne commented on 2012-06-05 04:52

short answer: I don't know

I haven't touched Mimeo for a while so I need to dig into it again to remember how and why it does things. Dealing with MIME-types is a mess because of the apparent lack of standardization. Some things have probably changed since the last major update too. Unfortunately, I just don't have the time right now to wrap my head around all of the documentation and sort it out. It wouldn't make much sense either because I plan to rewrite it in Python 3 when I do have time to spend on it. When I do, I will modularize (and denoobify) it and offload all of the standard XDG functions to my XDG module. Once everything is clearly organized it should be easy to add code to support different desktop "standards".

If you find a clean way to improve the existing code then I will look at it and consider patching it in if it works.

ninian commented on 2012-06-03 21:57

Am I correct in saying that the Python2 'mimetypes' module and the 'file' command don't utilize the XDG Shared MIME-info Database? (I've added some of my own mime types and of course, have then run 'update-mime-database' on the relevant directories.) Running 'mimeo -m <file>' and 'file --mime-type <file>' don't pick up these added mime-types, but for example, the 'mimetype' command (from the perl-file-mimeinfo package) and the 'rox -m' command do detect them. I see that the relevant lines in Mimeo.py are 725 - 727:
mimetype = mimetypes.guess_type(rpath)[0]
if not mimetype:
proc = subprocess.Popen(['file', '--mime-type', rpath], stdout=subprocess.PIPE)
Other than patching this file, would there be any possibility of allowing mimeo to use a different (more accurate) choice of mime-type finder - maybe in the configuration file or an option? (I know that I can put an entry in mimeo.conf to launch an application if the extension matches, but would prefer to handle the mime-type properly.)

ninian commented on 2012-06-03 21:50

Am I correct in saying that the Python2 'mimetypes' module and the 'file' command don't utilize the XDG Shared MIME-info Database? (I've added some of my own mime types and of course, have then run 'update-mime-database' on the relevant directories.) Running 'mimeo -m <file>' and 'file --mime-type <file>' don't pick up these added mime-types, but for example, the 'mimetype' command (from the perl-file-mimeinfo package) and the 'rox -m' command do detect them. I see that the relevant lines in Mimeo.py are 725 - 727:
mimetype = mimetypes.guess_type(rpath)[0]
if not mimetype:
proc = subprocess.Popen(['file', '--mime-type', rpath], stdout=subprocess.PIPE)
Other than patching this file, would there be any possibility of allowing mimeo to use a different (more accurate) choice of mime-type finder - maybe in the configuration file or an option? (I know that I can put an entry in mimeo.conf to launch an application if the extension matches, but would prefer to handle the mime-type properly.)

Xyne commented on 2012-06-02 14:33

I've replied on the forum.

ninian commented on 2012-06-02 08:01

I've found an issue with the path order in $XDG_DATA_DIRS being non-standard (see https://bbs.archlinux.org/viewtopic.php?id=142545).
I'm not using any DE, just Openbox and have no defaults.list or mimeapps.list files anywhere except /usr/local/share/applications/mimeapps.list. Mimeo doesn't pick up the default applications with the standard Arch $XDG_DATA_DIRS, but mimeo does find the defaults when XDG_DATA_DIRS="/usr/local/share/:/usr/share/"

dkasak commented on 2012-05-31 15:40

In case anyone wants the list_apps_by_mimetype.py script, it was moved here: http://xyne.archlinux.ca/scripts/system/list_apps_by_mimetype.py

misc commented on 2011-06-23 22:01

Cool! Thanks again.

Xyne commented on 2011-06-23 21:27

The second error should be fixed now.

There's no way to list associated apps by mimetype right now but I'll add that when I rewrite it in Python3 and clean up the code. All the necessary methods are already there. In the meantime, I've written a small script that does what you want:

http://xyne.archlinux.ca/miscellaneous/list_apps_by_mimetype.py

misc commented on 2011-06-23 09:57

(re previous post: Removing them manually, that is.)

Is there a way (for mimeo) to just display which apps a type is associated with?

misc commented on 2011-06-23 09:39

I got some other exits for a few orphaned wine entries such as:

File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2089, in main
mimeo.purge('nothing')
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1211, in purge
del desktops[basename]
KeyError: 'Mp3tag v2.46a.desktop

But after removing them mimeo works fine. Thanks!

Xyne commented on 2011-06-23 05:46

@misc
It should be fixed now. Upgrade and try again.

misc commented on 2011-06-21 15:31

Just installed it; I get

Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2089, in main
mimeo.purge('nothing')
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1211, in purge
del desktops[desktop_name]
NameError: global name 'desktop_name' is not defined

for e. g. "mimeo --add application/pdf zathura.desktop". (I use xmonad.)

Xyne commented on 2011-04-27 23:21

@reztho
It should be fixed now.

reztho commented on 2011-04-27 17:39

If I try to run the mimeman-help example, I have this:
% /usr/bin/mimeo --create feh.desktop Feh 'feh %f -F -Z' 'glob:image/*'
Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2028, in main
mimeo.create_desktop(*args)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 607, in create_desktop
desktop[DEG]['MimeType'] = self.get_matching_mimetypes(matcher, mime_types)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1554, in __setitem__
raise TypeError("type must be 'list' or 'str', not '%s'" % (value.__class__.__name__))
TypeError: type must be 'list' or 'str', not 'generator'

Xyne commented on 2011-04-13 15:20

The documentation has been updated. :)

Anonymous comment on 2011-04-12 07:40

No worries, fair enough. In that case, I should report a documentation error in the 'usage' section of mimeo --assoc-help :)

Association files can be specified on the command line. Mimeo will also load
$XDG_CONFIG_HOME/mimeo.conf or $HOME/.config/mimeo.conf as association files
if they exist. Which one depends on whether $XDG_CONFIG_HOME is set.

Xyne commented on 2011-03-26 11:57

It only checks the $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS directories (Mimeo.py sections starting at line 310 and line 395). It aims to be XDG compliant so it makes sense to only check those directories. Given that the location of the desktop entries depends on $XDG_DATA_*, it implicitly relies on the $XDG_* variables being set anyway.

Anonymous comment on 2011-03-24 19:43

I couldn't get mimeo to pay attention to an association file in $HOME/.config/mimeo.conf. Setting $XDG_CONFIG_HOME made it work fine. Looking at the source, I couldn't see anywhere where it would add the .config dir to the list of search paths for association files.

Is this a bug, or have i missed something?

xduugu commented on 2011-02-10 11:25

Thanks a lot. Fast as usual. 8)

Xyne commented on 2011-02-10 11:06

@xduugu
Error codes have been implemented. It now exits with 1 at the end of the operation if any argument generates an error.

xduugu commented on 2011-02-09 14:10

Could you implement error codes in future releases? Currently, you cannot tell if mimeo managed to handle the input or not. Thanks.

$ mimeo blah
error: no associations for MIMEtype ERROR: cannot open `/blah' (No such file or directory)
$ echo $?
0
$ mimeo http://google.com
error: no associations for MIMEtype application/x-msdos-program
$ echo $?
0

ammon commented on 2011-02-05 00:43

Yep, that fixes it. Thanks.

Xyne commented on 2011-02-05 00:13

@ammon
It should work now. It was probably caused by an empty line in one of the MIME cache files. If will now skip those. If it was caused by a malformed line then it will print a warning to STDERR.

ammon commented on 2011-02-04 17:43

I got this after update yesterday.


Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 603, in main
mimeo = Mimeo(options.term)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 166, in __init__
self.load_mimeinfo()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 242, in load_mimeinfo
self.load_mime_cache(fpath)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 293, in load_mime_cache
mimetype, desktops = map(lambda x: x.strip(), line.split('=', 1))
ValueError: need more than 1 value to unpack

I wanted to downgrade, to 2010.11 but package is no longer in your repo Xyne.

Schnouki commented on 2011-02-03 11:56

Thanks for the explanation, this makes sense now :)
And thanks for fixing it so quickly!

Xyne commented on 2011-02-03 11:36

That should have been:
def curry(cmd, regex)
  def fun(arg):
    ...
  return fun

Xyne commented on 2011-02-03 11:31

I think I discovered that error before but I re-introduced it when I refactored the code. I originally had a separate top-level function, something like

def curry(cmd, regex):
def fun(arg):
...
return fun

I had forgotten why I did that and I thought it could be replaced by a local function definition. I only tested the code with a single line in the association file so I missed the error. I don't understand why the local definitions all point to the same function either.

I have applied your changes as I think that is a better approach than recreating the top-level currying function. Thanks for the patch. :)

Schnouki commented on 2011-02-03 10:08

Thanks for the fix! :)

The other error still happens for me, but I have a patch that fixes it.

Apparently there is an issue with the "fun(arg)" functions defined in parse_association_file().
If you add a "print cmd, regex" inside, you will notice that when they are called (from parse_association_file()), they all have cmd=[last command from ~/.config/mimeo.conf] and regex=[last regex from ~/.config/mimeo.conf]. I don't understand why (I basically agree with your approach), but so it is.
Little demo:
Here is my mimeo.conf: https://github.com/Schnouki/dotfiles/blob/master/mimeo.conf

$ mimeo http://google.fr
/usr/bin/thunderbird -compose ^mailto:
/usr/bin/thunderbird -compose ^mailto:
/usr/bin/thunderbird -compose ^mailto:
/usr/bin/thunderbird -compose ^mailto:
/usr/bin/thunderbird -compose ^mailto:
/usr/bin/thunderbird -compose ^mailto:
error: no associations for MIMEtype ERROR: cannot open `/home/schnouki/http:/google.fr' (No such file or directory)

Here is my patch: http://pastebin.com/Kj7wBeuN
It replaces the "fun()" function by a simple (cmd, regex) tuple, which works flawlessly for me.

Xyne commented on 2011-02-03 04:01

@Schnouki
I've updated it to:
launchers.extend( self.launchers )
self.launchers = launchers

The new launchers should occur before the old ones in the list so that they take precedence.

I can't reproduce the other error, but maybe I fixed that with one of the updates last night.


As for Git, moving all of my code to Git repos is on my todo list, but I just haven't had the time.

Schnouki commented on 2011-02-02 18:09

This version is very broken for me... I'm using only the default association file ~/.config/mimeo.conf, and now everytime I try to run mimeo with an URL I get this:

$ mimeo http://google.com
Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 622, in main
for cmd in mimeo.get_cmds(*args):
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 535, in get_cmds
cmd = get_custom_launcher(self.launchers, arg)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 90, in get_custom_launcher
for l in launchers:
TypeError: 'NoneType' object is not iterable

This can be fixed at line 199 of Mimeo.py, by replacing self.launchers = launchers.extend(...) with self.launchers.extend(launchers)
("extend" changes the list *in place*.)

After this fix is applied, I get these:
$ mimeo http://google.fr
error: no associations for MIMEtype ERROR: cannot open `/home/schnouki/http:/google.fr' (No such file or directory)
$ mimeo http://google.com
error: no associations for MIMEtype application/x-msdos-program

After that, I just reverted to an older version of mimeo from a recent backup, and now it works again :)
Could you please look into these issues? (Also, it would be very nice to have a public Git repository for mimeo, so that other can contribute more easily :))

Xyne commented on 2010-11-02 18:44

Ok, I've uploaded a new version with the changes. I rearranged the loading order so that the user can override associations in the default configuration file with those in others.

Schnouki commented on 2010-11-02 17:49

Nice, thanks! :)

Xyne commented on 2010-11-02 17:36

Disregard my last comment if you received it via email. I misunderstood the purpose of the patch at first (by confusing the custom associations file with the MIMEtype associations file).

I'm on my way out the door right now but I'll try to add this tonight when I get back if I have time (and remember).

Thanks.

Xyne commented on 2010-11-02 17:29

Thanks, Schnouki.

I want mimeo to remain compatible with mimeman and obfilebrowser so I'll need to consider this in detail when I have time. I'll mention the patch on the project page for now.

Schnouki commented on 2010-11-02 16:47

Here is a little patch that makes mimeo autoload ~/.config/mimeo.conf as an association file: http://aur.pastebin.com/BUMzLeMt.
Useful for me with xdg-utils-mimeo (I don't use a DE nor a file manager, just Awesome, Chromium and a few terminals) so I can handle my associations with just a single text file (including URLs such as "spotify:...").

Xyne commented on 2010-08-02 21:51

I've replaced
mimetypes.init()

with
mimetypes.init(["/etc/mime.types", os.path.expanduser('~/.mime.types')])

Thanks.

matthewbauer commented on 2010-08-02 20:48

With the default mimeo, the local ~/.mime.types are not loaded for me. I think it is a bug in the Python mimetypes module.

I made this patch to fix it:
http://aur.pastebin.com/RPPXcZB9