You are not logged in.
Sorry for the delayed response.
Without an example, I do not know what you were trying to do (e.g. clear all associations for a MIME-type, all associations for a desktop file or a combination of MIME-types and a desktop file). Looking at the code I found 2 bugs that prevented clearing all associations for a given MIME-type. Those have been fixed and the following now works: "mimeo --clear foo/bar".
The default behavior for clearing a desktop's associations may be counter-intuitive: "mimeo --clear foo.desktop" will remove "foo.desktop" from all MIME-types listed in the desktop file. To completely clear "foo.desktop", use "mimeo --clear 'glob:*' foo.desktop". I have updated the help message to make this clearer. I hesitated to make this behavior the default with this update but the current behavior is coherent with the other operations and keeps the common function simple.
If neither the bug fix nor the usage clarification address your issue, please post a specific example with relevant entries from the mimeapps.list file.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
I'm having an issue when a document has a subtype of a particular mime type, i.e. image/vnd.djvu+multipage instead of image/vnd.djvu:
[archie@thinkpad ~]$ mimeo --show-all KnuthII.djvu
WARNING: failed to determine command precursor for KnuthII.djvu
WARNING: failed to determine command(s) for KnuthII.djvu
[archie@thinkpad ~]$ mimeo -m KnuthII.djvu
KnuthII.djvu
image/vnd.djvu+multipage
[archie@thinkpad ~]$ file --mime-type KnuthII.djvu
KnuthII.djvu: image/vnd.djvu
cf. this qpdfview bug where the author decided to match all subtypes:
https://bugs.launchpad.net/qpdfview/+bug/1515018
Not sure if a given desktop file should contain subtypes of a given MIME type, or if the opener should simply count those as part of the main mime type. Also the guy who broke it:
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I was unaware that MIME-types may consist of the following:
top-level type name / subtype name [ ; parameters ] top-level type name / [ tree. ] subtype name [ +suffix ] [ ; parameters ]
When I have the time, I will add a full MIME-type parser to handle the different components and default to using the main type if no association exists for the subtype. In the meantime, just add associations for each fully qualified type.
I may also add an option to create associations directly from a path argument.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Nice, looking forward to the change.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Both changes have been implemented. If testing for filepath arguments leads to conflicts then I will revert to the previous behavior and add an option to enable this new behavior.
Usage example:
mimeo --prefer /path/to/some/movie.mkv vlc.desktop
Qualified MIME-types (e.g. foo/bar+wuz) will default to unqualified associations (e.g. foo/bar) if no qualified associations are found.
Let me know if you find a bug.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Hmm, mimeo does not use ~/.config/mimeo.conf for me, I have to specify it with the -a option.
Even when I try to run it with
XDG_CONFIG_HOME="$HOME/.config" mimeo foobar
it does not use the config.
**EDIT** (Reading is hard)
--filepath-help showed me the way...
custom associations, in order:
/home/carnager/.config/mimeo/associations.txt
/etc/xdg/mimeo/associations.txt
Last edited by Rasi (2017-11-01 23:31:36)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
Maybe a dumb question, but is there any way to open terminal applications (like vim) using mimeo, but in the same shell instead of opening another window?
Currently I have my default arguments set to "--term 'urxvtc -e %s'", but it creates another window with urxvt.
Offline
Sathors, could you describe a bit more what steps you are following?
Offline
For example, I have text/plain associated to neovim.
With my default arguments ("--term 'urxvtc -e %s'") set in .config/mimeo/default_arguments.txt, when I issue a
mimeo my_file.txt
, it opens another instance of urxvt and opens neovim there. I would like for mimeo to open neovim in the same shell, then once I quit the neovim process, get the prompt back.
I have tried many different things and I was not able to get it to work.
This problem is independant of neovim itself, I only want to open --term commands in the same shell.
Offline
@Sathors
The "--term" option determines how terminal applications are opened. If you set it to "urxvtc -e %s",then every time mimeo detects that a file should be opened with vim in the terminal, it will run "urxvtc -e vim ..." and launch a new urxvt window. Just omit that option to have to run vim directly in the same terminal (and return to it when vim exits).
Note that by removing that option, any non-terminal application that launches a terminal application via mimeo will not show it to the user (and will probably freeze waiting for the command to finish). I suggest leaving your current default arguments and creating a separate alias for working in a terminal.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
@Xyne
I have removed everything from my default_arguments.
But now when I run
mimeo my_file.txt
, it does open neovim in the current shell, but hitting any key gets me back to the prompt. It seems that mimeo is not waiting for neovim to quit. The key I hit while seeing nvim interface is actually written on the prompt. The neovim session gets killed when hitting the key.
Any idea?
Offline
@Xyne
Any idea?
Nope. Does the same happen with regular vim?
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Well at least by using vim, I am beginning to see a real error.
+ ~$ mimeo --command work/gtd/retrospectives.md
vim work/gtd/retrospectives.md
+ ~$ mimeo work/gtd/retrospectives.md
Vim: Error reading input, exiting...
Vim: Finished.
+ ~$ vim work/gtd/retrospectives.md
So mimeo explicitly states that it will run `vim work/gtd/retrospectives.md`. When I run mimeo (with vim instead of nvim), I get exactly the same behavior (vim terminates on first keyboard input), but at least the error gets echoed explicitly in the terminal. When I run the command myself, everything works as expected.
Just to be sure I disabled my .vimrc and my .vim directory.
Could it be something with the TERM variable that mimeo sets or something along those lines?
Last edited by Sathors (2018-11-19 15:34:40)
Offline
Hey Xyne,
although you said that the problem with 'file://' paths has been fixed I still seem to have problems
with it. I didn't find anything in this thread (or anywhere else for that matter) that could resole
my issue. I hope I haven't overlooked something.
Qutebrowser denied to open files instead of saving them so I tried opening those with xdg-open which
resulted in
WARNING: failed to determine command precursor for file://
I dug through Mime.py a little and thought I could do a very dirty fix. Just to get it running for
now. I think the culprit might be line 1642 which evaluates to false (since I don't have any custom
mimeo associations).
So I know that I can add associations for specific protocols such as 'http://'. This should work
fine for 'file://' just as well but the problem is that I still would need to differentiate between
PDFs, PNGs, HTMLs etc.
Is there any way of making this work again? I would like to keep this as flexibel as possible
so that I don't have to specify 'file:// {filetype}' for everything I want to open from qutebrowser.
For the record: xdg-open from the xdg-utils package works fine. I would still prefer mimeo though. It's just a little more intuitive.
Thanks so much
Lukas
Last edited by Kampfpudding (2018-11-22 09:06:43)
Offline
@Sathors
I have updated Mimeo to handle terminal commands without a user-provided terminal option. To prevent hanging programs that use mimeo internally, it will check that both stdin and stdout are interactive and exit with an error if not.
@Kampfpudding
Can you provide an example? The error message that you posted indicates that something is passing the argument "file://" without any path to mimeo, which is the only way that I can reproduce the error. Opening file URIs works if they are valid:
> mimeo -c file:///tmp/test.txt file:///tmp/foo.htm
vim /tmp/test.txt
qutebrowser file:///tmp/foo.htm
Paths are extracted from file URIs and handled the same way as regular path arguments, which included MIME-type detection, so no additional configuration is required. The above example was run without a custom associations file.
I suspect there is an error in your qutebrowser and/or xdg-open configuration.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
@Xyne
Thank you, it is now working perfectly!
Offline
Sure:
mimeo -c file:///tmp/qutebrowser-downloads-zjd8ds9u/tmp2j_uj0zm_Checkliste-Barrierefreies-PDF.pdf
This PDF has been downloaded with qutebrowser. I chose "Open" instead of "Store", that's why it was put into /tmp.
Running this command I get
WARNING: failed to determine command precursor for file:///tmp/qutebrowser-downloads-zjd8ds9u/tmp2j_uj0zm_Checkliste-Barrierefreies-PDF.pdf
Since it seems to work for everybody else I'd assume it's a problem on my end. I'll try to dig a bit deeper. Debugging my system should really not be your responsibility
Offline
@Kampfpudding
Did you manage to solve the problem?
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Well, since xdg-open worked for now and I didn't see the need for mimeo's extra features I actually didn't even try to solve the problem. Maybe I'll find during the christmas holidays. Thanks for remembering, though
Offline
I'm having issues trying to associate some wine application with a filetype.
mimeo --add audio/x-ptb wine-extension-ptb.desktop
But I get:
mimeo --mime2desk audio/x-ptb
audio/x-ptb
tuxguitar.desktop
wine-extension-ptb.desktop is located in ~/.local/share/applications
Offline
@Pastah
Use "--prefer" instead of "--add" to set the default association. Use "--show-all" with commands such as "--mime2desk" to list all associations (e.g. "mimeo --mime2desk audio/x-ptb --show-all").
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Hi,
Recently I came across the same issue as Kampfpudding. When i try opening a file with mimeo using the "file://" uri i get these warnings and the file won't open. And it won't differentiate between a pdf, or another file type, and folders:
$ mimeo -c "file:///home/femto/2019-0219.pdf" "file:///home/femto/"
WARNING: failed to determine command precursor for file:///home/femto/2019-0219.pdf
WARNING: failed to determine command precursor for file:///home/femto/
WARNING: failed to determine command(s) for file:///home/femto/2019-0219.pdf file:///home/femto/
$ mimeo -m "file:///home/femto/2019-0219.pdf" "file:///home/femto/"
file:///home/femto/2019-0219.pdf
x-scheme-handler/file
file:///home/femto/
x-scheme-handler/file
I'm currently not using any Desktop Environment, and have xdg-utils-mimeo installed so it fallbacks to mimeo.
$ pacman -Q mimeo xdg-utils-mimeo
mimeo 2018.12-1
xdg-utils-mimeo 1.1.3-1
I also tried using xdg-utils from the official repos, and got no problems with "file://" URIs.
Thanks
Offline
I'm unable to reproduce the error. All arguments are parsed as potential URIs and their paths are automatically extracted so file URIs should yield the same results as plain paths. The only difference should be that file URIs also include x-scheme-handler/file types as a final MIME-type when mimeo is invoked with the "--show-all" option.
I've modified the code to handle empty hosts as a special case to ensure that the path is returned. I suspect that the problem is missing MIME info on your system. There used to a MIME-types package which was listed as an optional dependency, but it seems that has disappeared. I think the "shared-mime-info" package replaced it so I have updated the PKGBUILD. Please install that and the new version of mimeo and test again.
If it still doesn't work, please post the output when invoked with both the file URI and the plain path to confirm that the MIME-types are detectable.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Hi, thanks for replying.
I've installed the new 2019.3 PKGBUILD and the file:// URIs are now working properly. And although the MIME-types packages is no longer listed, when I checked my installed packages I found that shared-mime-info package was already installed.
Thank you very much.
Offline
Hi guys. Anyone else has a broken xdg-open after upgrading to python 3.8?
➜ xdg-open https://www.google.com
/usr/bin/python3: No module named Mimeo
➜ mimeo --help
/usr/bin/python3: No module named Mimeo
➜ cat /usr/bin/mimeo
#!/bin/bash
/usr/bin/python3 -m Mimeo "$@"
Asking here because it's referenced from the mimeo project page: https://xyne.archlinux.ca/projects/mimeo/
The changelog doesn't say anything after 2017/06. Is mimeo deprecated, and should I switch to another tool?
Offline