Package Details: mimeo 2021.11-3

Git Clone URL: https://aur.archlinux.org/mimeo.git (read-only, click to copy)
Package Base: mimeo
Description: Open files by MIME-type or file name using regular expressions.
Upstream URL: https://xyne.dev/projects/mimeo
Keywords: utilities
Licenses: GPL
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 139
Popularity: 0.95
First Submitted: 2009-12-16 02:54 (UTC)
Last Updated: 2021-12-13 22:15 (UTC)

Latest Comments

Xyne commented on 2021-12-14 16:16 (UTC)

You can also use my repo to update automatically if you're not using an AUR helper. https://xyne.dev/repos/

nyi commented on 2021-12-14 12:03 (UTC)

@komex: Reinstalling the AUR package should fix that error. It is caused by a Python upgrade, but your AUR python packages are not aware of the upgrade. You thus need to rebuild all AUR packages using python.

komex commented on 2021-12-13 14:08 (UTC) 

$ miemo
Traceback (most recent call last):
  File "/usr/bin/mimeo", line 5, in <module>
    from Mimeo import run_main
ModuleNotFoundError: No module named 'Mimeo'

How to fix it?

Xyne commented on 2021-11-12 04:11 (UTC)

@johnhamelink That's expected. Even though my key is in the Arch Linux keyring on the system, makepkg only uses the user's keyring so all keys have to be imported by the user.

johnhamelink commented on 2021-10-03 14:19 (UTC)

Hi there, I was struggling to download this tool with the default PKGBUILD as the keyserver that was used was not resolving. Importing like so allowed me to install correctly:

gpg --recv-keys --keyserver keyserver.ubuntu.com 1D1F0DC78F173680

Poroing commented on 2021-02-11 18:23 (UTC) (edited on 2021-02-11 18:26 (UTC) by Poroing)

In the mimeo script, in the shebang line, the path to the interpreter isn't absolute. That should be the case (See https://en.wikipedia.org/wiki/Shebang_%28Unix%29#Syntax). It currently is #!python but should be something like /bin/env python or /usr/bin/pythin.

ectospasm commented on 2021-01-07 03:17 (UTC)

I worked around my problem. I had another AUR package (goobook), which depends on the AUR package python-xdg. python-xdg conflicts with the Community (non-AUR) package python-pyxdg. python-xdg and python-pyxdg install to the same path if installed via pacman (or AUR PKGBUILD), so installing one means you have to uninstall the other, and any Python package depending on the other will be broken.

I was able to work around the conflict by using a Python venv for python-xdg. See https://bbs.archlinux.org/viewtopic.php?id=262403 for details on how exactly I fixed it.

ectospasm commented on 2020-12-28 22:48 (UTC) (edited on 2020-12-28 22:49 (UTC) by ectospasm)

mimeo is broken for me, and it looks like it has to do with the python-xdg/python-pyxdg dependency conflict:

Traceback (most recent call last):
   File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
       return _run_code(code, main_globals, None,
   File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
       exec(code, run_globals)
   File "/usr/lib/python3.9/site-packages/Mimeo.py", line 58, in <module>
       import xdg.BaseDirectory
 ModuleNotFoundError: No module named 'xdg.BaseDirectory'

I upgraded another Python package that requires python-xdg. python-xdg conflicts with python-pyxdg. so I removed python-pyxdg. Even though mimeo appears to depend on python-xdg, it appears to be importing the python-pyxdg "xdg" modules. I believe this broke when Arch updated to Python 3.9 earlier this month.

ttoirrah commented on 2019-11-28 12:59 (UTC)

Xyne.archlinux.ca Status https://downforeveryoneorjustme.com/xyne.archlinux.ca "It's not just you! xyne.archlinux.ca is down." Hoping this is temporary...

Fandekasp commented on 2019-11-19 00:12 (UTC)

@Xyne indeed, sorry about that. I thought I had tried rebuilding the package, but I was wrong. Rebuilding the package fixed it, thanks for the quick support!

Xyne commented on 2019-11-18 23:55 (UTC)

@Fandekasp The AUR only provides PKGBUILDs, not built packages. It's up to the user to rebuild them when necessary. The PKGBUILD itself is not out-of-date. You just need to run makepkg again.

Nevertheless, I may bump the pkgrel when I rebuild the packages for my repo.

Fandekasp commented on 2019-11-18 00:44 (UTC)

Not sure if I should have not flagged the package out-of-date, but it's currently unusable since upgrading the system python from 3.7 to 3.8

$ mimeo /usr/bin/python3: No module named Mimeo

As per this comment: https://bbs.archlinux.org/viewtopic.php?pid=1873269#p1873269 We need to rebuild mimeo against Python 3.8

FunctionalHacker commented on 2019-11-07 09:08 (UTC)

Is there a completion file for zsh available?

lesiserfg commented on 2019-05-24 05:52 (UTC) (edited on 2019-06-10 15:07 (UTC) by lesiserfg)

Can you use /usr/bin/python3 instead of python3 cause it makes impossible to use mimeo inside of a virtualenvironment, please?

Xyne commented on 2018-05-30 15:49 (UTC) (edited on 2018-05-30 15:49 (UTC) by Xyne)

@Ataraxy

What's the output of the following commands?

pacman -Qi mimeo
pacman -Ql mimeo

Ataraxy commented on 2018-05-20 07:47 (UTC) (edited on 2018-05-20 07:47 (UTC) by Ataraxy)

At install time I see:

running install_egg_info
Writing /home/ravi/.cache/pacaur/mimeo/pkg/mimeo/usr/lib/python3.6/site-packages/Mimeo-2017.06.06.22.34.38-py3.6.egg-info

But something seems to be awry:

$ type mimeo
mimeo is hashed (/usr/bin/mimeo)
$ mimeo
/home/ravi/.local/share/miniconda3/bin/python3: No module named Mimeo

Xyne commented on 2017-09-09 15:20 (UTC)

Downloaded source files that you build and install should be verified to minimize security risks. Most AUR packages rely on checksums (and most of those are checksums generated by the maintainer when the package is updated, not provided by upstream). PGP signatures provide better security than checksums which is why support was added with the recent updates to the AUR website. Most packages still don't use them yet, either because upstream doesn't provide signed sources or because the maintainer simply hasn't updated to use them. As for why you have to install the key instead of letting makepkg do it automatically, it provides a little more security. If the file had been intentionally corrupted, then it would be easy to sign it with the attacker's key and makepkg wouldn't even notice. As it is now, users who want security can carefully verify public keys before trusting them (or just run a simple command to import them without caring). Btw, my key is in the Arch Linux keyring. Feel free to suggest on the pacman-dev list that makepkg first check with pacman-key before using the user's keyring ;)

commented on 2017-09-09 09:50 (UTC)

==> Verifying source file signatures with gpg... mimeo-2017.6.6.tar.xz ... FAILED (unknown public key 1D1F0DC78F173680) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build mimeo. sorry for being a noob but why does every other AUR-package install fine and for this one I have to go to the trouble of adding keys?

JP-Ellis commented on 2017-05-30 07:39 (UTC)

@Xyne Sorry I didn't see you replied. Python should always be installed to /usr/bin/python3 (at least on Arch Linux), so there is no harm in hard-coding this. This would also solve the issue encountered by @cswoodruff. Virtual environments are actually fairly common, especially for people who need to have multiple versions of Python installed (or Python libraries). You probably haven't had people raise the issue because the fix is so simple... but I still think it would be better if mimeo ensured that the system installation of Python is used every time as opposed to explicitly using "whichever bash prefers" even if it isn't the one where the Mimeo library is installed.

commented on 2017-03-10 17:44 (UTC)

It would be good if the PKGBUILD could be changed so that it uses an explicit call to python3. This ensures that python3 is always used during the build process for people like me that have a link in their path overriding the default python (/home/user/bin/python --> /usr/bin/python2).

Xyne commented on 2017-01-29 12:41 (UTC)

@toketin Looks like a temporary key server error. Try a different server or try again later.

toketin commented on 2017-01-22 21:07 (UTC)

$ gpg --recv-keys --keyserver hkp://pgp.mit.edu 1D1F0DC78F173680 gpg: ricezione dal keyserver fallita: Server indicated a failure

NuSkool commented on 2016-10-20 15:49 (UTC)

gpg --recv-keys --keyserver hkp://pgp.mit.edu 1D1F0DC78F173680

Xyne commented on 2016-09-07 21:04 (UTC)

@JP-Ellis The issue of virtual environments has come up only once before in the last 4-5 years (iirc) so it seems to affect very few people. I wonder if just as many would be affected by hard-coded paths. Given that I currently neither use virtual environments nor mess around with paths, I have no strong opinion on the matter. Given that the launcher scripts are just minimalist wrappers around the Python executable, I'm more inclined to just leave it as-is and let the user's who bother to set up a virtual environment set up their own aliases or wrappers as well. I'm remain open to arguments.

JP-Ellis commented on 2016-08-28 12:03 (UTC)

It would be good if /usr/bin/mimeo could be changed so that it uses an absolute path for Python (that is, replace "python3" with "/usr/bin/python3"). This ensures that the system python is always used and the mimeo module is available. This is an issue for people who use python virtual environments as the system modules are (generally) not made available in the virtual environment.

zoopp commented on 2016-01-25 19:13 (UTC) (edited on 2016-01-25 19:14 (UTC) by zoopp)

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 (UTC)

Thanks a lot for the fast fix/rewrite.

Xyne commented on 2016-01-13 01:37 (UTC)

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 (UTC) (edited on 2016-01-10 08:08 (UTC) by Xyne)

@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 (UTC)

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 (UTC)

> @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 (UTC)

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 (UTC)

Fix typo from pazpi's comment. yes it does work. gpg --recv-keys 1D1F0DC78F173680

pazpi commented on 2015-03-29 19:45 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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

Xyne commented on 2014-12-31 01:17 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

Thanks for the update btw.

Alad commented on 2014-12-01 06:54 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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

xduugu commented on 2013-02-10 12:31 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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

antihero commented on 2012-11-22 13:08 (UTC)

Here's a patch: https://gist.github.com/4131102

antihero commented on 2012-11-22 12:50 (UTC)

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 (UTC)

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

Xyne commented on 2012-10-22 23:56 (UTC)

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

commented on 2012-10-22 17:08 (UTC)

Signature file is not available.

ninian commented on 2012-06-05 16:59 (UTC)

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.

Xyne commented on 2012-06-05 04:52 (UTC)

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:50 (UTC)

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 (UTC)

I've replied on the forum.

ninian commented on 2012-06-02 08:01 (UTC)

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 (UTC)

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 (UTC)

Cool! Thanks again.

Xyne commented on 2011-06-23 21:27 (UTC)

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 (UTC)

(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 (UTC)

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 (UTC)

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

misc commented on 2011-06-21 15:31 (UTC)

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 (UTC)

@reztho It should be fixed now.

reztho commented on 2011-04-27 17:39 (UTC)

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 (UTC)

The documentation has been updated. :)

commented on 2011-04-12 07:40 (UTC)

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 (UTC)

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.

commented on 2011-03-24 19:43 (UTC)

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 (UTC)

Thanks a lot. Fast as usual. 8)

Xyne commented on 2011-02-10 11:06 (UTC)

@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 (UTC)

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 (UTC)

Yep, that fixes it. Thanks.

Xyne commented on 2011-02-05 00:13 (UTC)

@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 (UTC)

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 (UTC)

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

Xyne commented on 2011-02-03 11:36 (UTC)

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

Xyne commented on 2011-02-03 11:31 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

Nice, thanks! :)

Xyne commented on 2010-11-02 17:36 (UTC)

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.

Schnouki commented on 2010-11-02 16:47 (UTC)

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 (UTC)

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 (UTC)

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