Hello, Michiel,

Earlier I submitted this by email to [email protected]. I now see I should be using GitHub.

Hello, Jaap,

I have in mimeopen:

No known bugs, please mail the author if you find one.

See File::MimeInfo::Applications(3) and File::DesktopEntry(3)
for some limitations.
...
Copyright (c) 2002, 2012 Jaap G Karssenberg. All rights reserved.

And then a strangely UTF-8k named file:

515 $ Movie="L'Odyssée Cartier.flv"
516 $ ls -l "$Movie"
-rwxrwx--- 1 root vboxsf 13225664 Mar 26 2012 L'Odyssée Cartier.flv
517 $
517 $ # So far so good. But:
518 $
518 $ mimeopen -L -n "$Movie"
Opening "L'Odyssée Cartier.flv" with VLC media player (video/x-flv)
VLC media player 2.0.3 Twoflower (revision 2.0.2-93-g77aa89e)
[0x8f26908] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[0x925bf00] filesystem access error: cannot open file /media/sf_Shared/L'Odysse??e Cartier.flv (No such file or directory)
[0x9255930] main input error: open of `file:///media/sf_Shared/L'Odyssée Cartier.flv' failed

I notice the 0x925bf00 message has the filename corrupted, but 0x9255930
renders it correctly.

Have I stumbled into one of the limitations mentioned?

If I simply click on the file's icon in Thunar File Manager, Thunar opens it correctly with VLC.

Thanks,
gil

Hi Michiel,

I have the following bug:

Building and testing File-MimeInfo-0.28
cp lib/File/MimeInfo/Rox.pm blib/lib/File/MimeInfo/Rox.pm
cp lib/File/MimeInfo/Magic.pm blib/lib/File/MimeInfo/Magic.pm
cp lib/File/MimeInfo/Cookbook.pod blib/lib/File/MimeInfo/Cookbook.pod
cp lib/File/MimeInfo.pm blib/lib/File/MimeInfo.pm
cp lib/File/MimeInfo/Applications.pm blib/lib/File/MimeInfo/Applications.pm
cp mimeopen blib/script/mimeopen
"/usr/local/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/mimeopen
cp mimetype blib/script/mimetype
"/usr/local/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/mimetype
PERL_DL_NONLAZY=1 "/usr/local/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
WARNING: You don't seem to have any mimeinfo.cache files.
Try running the update-desktop-database command. If you
don't have this command you should install the
desktop-file-utils package. This package is available from
http://freedesktop.org/wiki/Software/desktop-file-utils/
t/00_use_ok.t ...... ok
t/01_normal.t ...... ok
t/02_magic.t ....... ok
t/03_rox.t ......... ok
t/04_IO_objects.t .. ok
t/05_more.t ........ ok
t/06_pod_ok.t ...... skipped: Test::Pod 1.00 required for testing POD
t/07_pod_cover.t ... skipped: Test::Pod::Coverage 1.00 required for testing POD coverage
t/08_changes.t ..... skipped: Test::CPAN::Changes 0.18 or later required for this test
t/09_no404s.t ...... skipped: Skip $ENV{EXTENDED_TESTING} is not set
WARNING: You don't seem to have a mime-info database. The
shared-mime-info package is available from http://freedesktop.org/ .
Can't locate object method "seek" via package "Path::Tiny" at /root/.cpanm/work/1533399953.10264/File-MimeInfo-0.28/blib/lib/File/MimeInfo.pm line 115.
t/10filehandle.t ... 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 

Test Summary Report
-------------------
t/10filehandle.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=11, Tests=76,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.54 cusr  0.07 csys =  0.65 CPU)
Result: FAIL
Failed 1/11 test programs. 0/76 subtests failed.
Makefile:918: recipe for target 'test_dynamic' failed
make: *** [test_dynamic] Error 2
-> FAIL Installing File::MimeInfo failed. See /root/.cpanm/work/1533399953.10264/build.log

I see that this bug is fixed in 0.28_3 but it appears not to have made it into 0.28

In Debian we are currently applying the following patch to
File-MimeInfo.
We thought you might be interested in it too.

Description: spelling fix
Origin: vendor
Author: gregor herrmann <[email protected]>
Last-Update: 2016-11-28

The patch is tracked in our Git repository at
https://anonscm.debian.org/cgit/pkg-perl/packages/libfile-mimeinfo-perl.git/plain/debian/patches/spelling.patch

Thanks for considering,
gregor herrmann,
Debian Perl Group

Hello.

When running (in a fresh 0.27 build directory):
PERLRUN=$PWD/blib perl -MFile::MimeInfo::Magic -e 'print(mimetype($ARGV[0]), "\n")' Makefile.PL
I get as expected:
application/x-perl
when adding -0777:
PERLRUN=$PWD/blib perl -0777 -MFile::MimeInfo::Magic -e 'print(mimetype($ARGV[0]), "\n")' Makefile.PL
I get:
Magic file '/usr/share/mime/magic' doesn't seem to be a magic file at -e line 1.
text/plain

Which isn't exactly expected.
Yours
Morten

Please provide a FreeDesktop-compatible *.desktop file for mimeopen, declaring that it handles application/octet-stream files, e. g.:

[Desktop Entry]
Type=Application
Version=1.0
Name=mimeopen
GenericName=Open with default application
Comment=Mime-type and file extension-aware file opener
Exec=mimeopen -n %F
Icon=system-run
Terminal=false
MimeType=application/octet-stream

This makes mimeopen available to xdg-aware applications as a handler of application/octet-stream files (i.e. unknown binary files) which are commonly transmitted over the internet, even when their binary fingerprint is not really unknown, e.g. when they are compressed archives, ODT or PDF documents, multimedia files, ...

Currently, whenever one clicks a browser link that results in a file download, Firefox asks to save it (because the server, as is very common, sent Content-Type: application/octet-stream header for this exact reason – to force a download). However, one may not wish to save the file explicitly, but open it (implicitly saved to /tmp). Mimeopen does a splendid job of opening that (i.e. any) file.

Thanks!

When selecting vim.desktop or nvim.desktop to open a file, the following error appears:

It also works if TERMINAL=kitty, but not alacritty.

Not sure if it's the problem with alacritty because nvim opens fine when using xdg-open.

I noticed that today my .bash_history file is shown as an Amiga-SoundTracker-Audio file in pcmanfm. These first three lines make mimetype -M detect it as audio/x-mod:

if [[ "hallo" =~ "hallo" ]] ; then echo test; fi
if [[ "hello" =~ "hallo" ]] ; then echo test; fi
if [[ "hello" =~ "h.llo" ]] ; then echo test; fi

I hope this is the right place to put this issue.

An m4a file with a jpeg image embedded in the covr tag causes mimetype -M to return video/mp4 when mimetype without -M returns audio/m4a. This removes the usefulness of using mimetype to verify that some m4a is actually what it claims to be, an mp4 with only audio.

If I use mimeopen to open a file called "ä.pdf" (umlaut a encoded in UTF8), my associated application does not find the file (the error message is somewhat strange):

thomas.bartosik@tbartosik-linux:/mnt/scratch$ xdg-open ä.pdf 
Opening "ä.pdf" with Zathura  (application/pdf)
exec string: zathura ä.pdf
error: Unknown file type: '(null)'

If I uncomment

165 #print STDERR "exec string: ".$default->parse_Exec(@ARGV)."\n";

everything still looks OK on the console output.

An strace clearly shows the wrong (double?) encoding:

thomas.bartosik@tbartosik-linux:/mnt/scratch$ strace mimeopen -n ä.pdf 2>&1 | grep "open.*pdf"
execve("/usr/bin/mimeopen", ["mimeopen", "-n", "\303\244.pdf"], [/* 43 vars */]) = 0
open("\303\244.pdf", O_RDONLY)          = 4
open("/etc/fonts/conf.d/99pdftoopvp.conf", O_RDONLY|O_CLOEXEC) = 11
open("/usr/lib/zathura/pdf.so", O_RDONLY|O_CLOEXEC) = 11
open("/mnt/scratch/\303\203\302\244.pdf", O_RDONLY) = -1 ENOENT (No such file or directory)

If I add

use utf8::all;

to mimeopen, all is well.

I am not a perl programmer and don't know about possible other implications, but it works for me.

Version used:

thomas.bartosik@tbartosik-linux:/mnt/scratch$ apt-cache policy libfile-mimeinfo-perl
libfile-mimeinfo-perl:
  Installed: 0.26-1
  Candidate: 0.26-1
  Version table:
 *** 0.26-1 0
        500 http://debian.inode.at/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

Environment:

thomas.bartosik@tbartosik-linux:/mnt/scratch$ set | egrep "^(LC_|LANG)"
LANG=en_US.UTF-8
LC_NUMERIC=de_AT.UTF-8
LC_PAPER=de_AT.UTF-8

Hi!
For some reason mimetype out.txt returns video/mp2t instead of text/plain.
Removing 10 lines we get a text file.

The file is attached: out.txt

OS: Ubuntu 20.04
version: mimetype 0.29

When mime database contains types with same glob patterns, mimetype always pick up the first type and doesn't use magics. It broke this recommendation.

Example database content:

<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
  <mime-type type="application/x-foobin">
    <comment>foo file (binary)</comment> 
    <glob pattern="*.foo"/>
    <magic priority="50">
      <match value="I am binary foo!" type="string" offset="0"/>
    </magic>
  </mime-type>
<mime-type type="text/x-foo">
    <comment>foo file</comment> 
    <glob pattern="*.foo"/>
    <magic priority="50">
      <match value="I am text foo!" type="string" offset="0"/>
    </magic>
  </mime-type>
</mime-info>

Example.foo

I am text foo!

After updating MIME database mimetype should return "text/x-foo":

$ mimetype --database=mime Example.foo
Example.foo: application/x-foobin
$ mimetype --database=mime -a Example.foo
Example.foo: application/x-foobin
Example.foo: text/x-foo
Example.foo: text/plain
$ mimetype --database=mime -D Example.foo
> Data dirs are: mime
> Checking inode type
> Checking globs for basename 'Example.foo'
> Checking for extension '.foo'
Example.foo: application/x-foobin

And if globs disabled:

$ mimetype --database=mime  -M Example.foo
Example.foo: text/x-foo

It seems that without rinning ::rehash() first,

$File::MimeInfo::Magiv::max_buffer is not defined and that results in readling 0 Bytes from stdin in the following line:

read(STDIN, $data, $File::MimeInfo::Magic::max_buffer);

The patch is tracked in the Debian GIt repository at

https://anonscm.debian.org/cgit/pkg-perl/packages/libfile-mimeinfo-perl.git/plain/debian/patches/fix_read_from_stdin.patch

Thanks for considering.
Simon Kainz,
Debian Perl Group

Standard http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html defines that default application associations should be first searched in $XDG_CONFIG_HOME, then $XDG_DATA_HOME (among other directories). This makes it possible to ship some distribution-wide defaults, while allowing user to choose some personal preferences.
Currently mimeopen ignores the later files - when no personal preferences are set, it basically choose "random" application (first on the list) as default (when -n is used). Even if some system-wide default is set.

The documentation says (many times) "mimetype($file)". What EXACTLY is $file??? The name of a file? A FileHandle or IO::File object? A scalar holding the contents of a file? Please clarify!

Using the option --ask with mimeopen, the terminal where mimeopen is executed on remains hang up until the launched application is closed.

It would be useful for an option or some workaround for being able to keep using the terminal where mimeopen is executed on without closing the launched application.

Thanks for your attention.

Consider the following file:

#!/bin/bash
#%PDF-
echo "you've been pwned"

mimetype($filehandle) returns application/pdf, but the file runs as a bash script.

Using File::MimeInfo::Magic v0.27.

For some reason, this exit 7 is executed even if execution went correctly:

Removing the offending line results in correct execution and the correct error code (0).

This is a problem since xdg-open, if it doesn't detect a known desktop environment, uses mimeopen if it's available, and checks its exit code. If it's nonzero, execution continues as if mimeopen failed, resulting in xdg-open opening the file multiple times.

This is described in more detail on Gentoo Forums, albeit nobody pointed out it was an issue with mimeopen.

Hello,

Some time ago I wrote a Moo(se) Role that added some recursive behaviour to mimetype_isa. This was a very quick-and-dirty solution at the time, in order to obviate cutting and pasting the same couple dozen lines of code. Of course, not everything is suitable to be written in Moo(se).

As such I am wondering if you're interested in accepting a patch. I decided on this overture rather than going and diving straight into a pull request because I want some input beforehand:

The behaviour of my mimetype_isa is such that it returns true if the $type and $parent are the same, and will likewise return true if either $type or $parent is an alias or deprecated type identifier, as well as if $parent is not an immediate ancestor of $type. These cases (since last I checked) all return false in File::MimeInfo.

Anyway, since this behaviour is significantly different, I'm wondering if it would make sense to patch in a mimetype_isa_deep or add a flag to mimetype_isa to switch on this behaviour.

That is—of course—if you're interested in the offer.

lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty

aptitude show libfile-mimeinfo-perl
Package: libfile-mimeinfo-perl
State: installed
Automatically installed: no
Version: 0.22-1
Priority: optional
Section: perl
Maintainer: Ubuntu Developers [email protected]
Architecture: all
Uncompressed Size: 142 k
Depends: perl, libfile-basedir-perl, libfile-desktopentry-perl, shared-mime-info
Description: Perl module to determine file types
File::MimeInfo can be used to determine the mime type of a file. It tries to implement the freedesktop specification for
a shared MIME database.

This package also contains two related utilities:

• mimetype: determine a file's mimetype
• mimeopen: open files according to their mimetype
  Homepage: https://metacpan.org/release/File-MimeInfo

If a file does not contain the <html> tag, /usr/bin/mimetype identifies the file as text/plain. /usr/bin/file seems to be more intelligent, or more tolerant, in this regard.

This is perl 5, version 24, subversion 0 (v5.24.0) built for darwin-2level
(with 1 registered patch, see perl -V for more detail)

Here are the results of cpanm File::MimeInfo

cpanm (App::cpanminus) 1.7042 on perl 5.024000 built for darwin-2level
Work directory is /Users/cwhitener/.cpanm/work/1484078023.15266
You have make /usr/bin/make
You have LWP 6.15
You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3
You have /usr/bin/unzip
Searching File::MimeInfo () on cpanmetadb ...
--> Working on File::MimeInfo
Fetching http://www.cpan.org/authors/id/M/MI/MICHIELB/File-MimeInfo-0.28.tar.gz
-> OK
Unpacking File-MimeInfo-0.28.tar.gz
Entering File-MimeInfo-0.28
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.24)
Configuring File-MimeInfo-0.28
Running Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for File::MimeInfo
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have Pod::Usage 0 ... Yes (1.69)
Checking if you have Fcntl 0 ... Yes (1.13)
Checking if you have Carp 0 ... Yes (1.40)
Checking if you have File::DesktopEntry 0.04 ... Yes (0.22)
Checking if you have Exporter 0 ... Yes (5.72)
Checking if you have File::BaseDir 0.03 ... Yes (0.07)
Building and testing File-MimeInfo-0.28
cp lib/File/MimeInfo/Rox.pm blib/lib/File/MimeInfo/Rox.pm
cp lib/File/MimeInfo.pm blib/lib/File/MimeInfo.pm
cp lib/File/MimeInfo/Magic.pm blib/lib/File/MimeInfo/Magic.pm
cp lib/File/MimeInfo/Applications.pm blib/lib/File/MimeInfo/Applications.pm
cp lib/File/MimeInfo/Cookbook.pod blib/lib/File/MimeInfo/Cookbook.pod
cp mimeopen blib/script/mimeopen
"/Users/cwhitener/perl5/perlbrew/perls/perl-5.24.0/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/mimeopen
cp mimetype blib/script/mimetype
"/Users/cwhitener/perl5/perlbrew/perls/perl-5.24.0/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/mimetype
Manifying 2 pod documents
Manifying 5 pod documents
PERL_DL_NONLAZY=1 "/Users/cwhitener/perl5/perlbrew/perls/perl-5.24.0/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
WARNING: You don't seem to have any mimeinfo.cache files.
Try running the update-desktop-database command. If you
don't have this command you should install the
desktop-file-utils package. This package is available from
http://freedesktop.org/wiki/Software/desktop-file-utils/
t/00_use_ok.t ...... ok
t/01_normal.t ...... ok
t/02_magic.t ....... ok
t/03_rox.t ......... ok
t/04_IO_objects.t .. ok
t/05_more.t ........ ok
t/06_pod_ok.t ...... ok
WARNING: You don't seem to have any mimeinfo.cache files.
Try running the update-desktop-database command. If you
don't have this command you should install the
desktop-file-utils package. This package is available from
http://freedesktop.org/wiki/Software/desktop-file-utils/
t/07_pod_cover.t ... ok
t/08_changes.t ..... ok
t/09_no404s.t ...... skipped: Skip $ENV{EXTENDED_TESTING} is not set
WARNING: You don't seem to have a mime-info database. The
shared-mime-info package is available from http://freedesktop.org/ .
Can't locate object method "seek" via package "Path::Tiny" at /Users/cwhitener/.cpanm/work/1484078023.15266/File-MimeInfo-0.28/blib/lib/File/MimeInfo.pm line 115.
t/10filehandle.t ...
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run

Test Summary Report
-------------------
t/10filehandle.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=11, Tests=89,  1 wallclock secs ( 0.04 usr  0.02 sys +  0.63 cusr  0.09 csys =  0.78 CPU)
Result: FAIL
Failed 1/11 test programs. 0/89 subtests failed.
make: *** [test_dynamic] Error 2
-> FAIL Installing File::MimeInfo failed. See /Users/cwhitener/.cpanm/work/1484078023.15266/build.log for details. Retry with --force to force install it.

Hi there. Thanks for mimeopen and associated modules.

From the docs for File::MimeInfo::Applications:

At present the file with defaults is $XDG_DATA_HOME/applications/defaults.list. This file is not specified in any freedesktop spec and if it gets standardized it should probably be located in $XDG_CONFIG_HOME.

There now seems to be a standard, and the chosen filename is mimeapps.list.

As expected, symlinking defaults.list to mimeapps.list makes mimeopen use the preferences I've expressed with various graphical file managers.

Well done also for anticipating the directory move.

Invoking mime_applications on a mime type for which no applications are found yields a bunch of warnings to the terminal:

$ perl -MFile::MimeInfo::Applications  -wE "mime_applications q[application/octet-stream]"
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 117.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 117.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 117.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 117.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 117.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 117.

(If you have a handler for application/octed-stream, I think just making up a Mime type would demonstrate the issue.)

I think the cause is in _find_file(). _default() invokes it like this:

my @list = _read_list(@paths);
my $desktop_file = _find_file(reverse @list);

If no handlers are specified, _read_list() returns an empty list, so inside _find_file(), @_ is empty. But the start of _find_file() is:

sub _find_file {
    my @list = shift;
    for (@list) {

shift returns a scalar value, so when @_ is empty, @list gets set to (undef). The for loop then iterates over that undef, and warnings ensure.

That for loop is also odd when @_ does contain multiple values: the first one gets shifted into @list and is processed by the loop — but either way the loop runs precisely once, making the looping part unnecessary.

I'm wondering if it should be:

sub _find_file {
    my @list = @_;
    for (@list) {

That would avoid looping at all when @_ is empty, and would also mean that when it isn't empty would loop over all its items, not just the first.

If it's desirable only to ‘loop’ over the first then maybe putting return undef if !@_ at the very top of the sub would do that and avoid the warnings.

Thanks.

The problem

If you have a mimetype without application associated (for instance "inode/application" (open directory) in my case, but it is independent of the mimetype), by default the user is asked for the application and has only the choice " 1) Other...".

$ mimeopen my_directory/
Please choose a default application for files of type inode/directory

        1) Other...

use application #

This is the expected behaviour, everything's fine.

But if I set the "-n" option (no-ask), then mimeopen crashes with:

$ mimeopen -n my_directory/
Can't call method "get_value" on an undefined value at ./mimeopen line 159.

Is this the intended behaviour ? It might be reasonible to crash (since we have no default to choose and we can't ask the user), but it is surprising to crash that way, exposing internal details of the script.

I think it would be better to print nothing, not to try to open the file, and return an error code. In any case, we should at least clarify in the doc what is the expected behaviour in that case.
I can do the patch, but I'm waiting for you opinion on whether this behaviour is ok for you.

Why does it happen

-> If no application is found for the mimetype, then $default is undef and @other is an empty array (l. 137). Then, with -n, we enter the if block on l. 146. On l. 147, define($default) is false, so the new $default is $other[0] which is also undef. No further check of undef are done until l. 159 where we do $default->get_value(...).

Even though the app is fully functional, I am getting errors when running mimeopen.
for example, when I try to run mimeopen with the following command:
mimeopen -Da dmenuhandler
I am getting this output:

> Data dirs are: /home/dusan/.local/share, /usr/local/share, /usr/share
> Checking inode type
> Checking globs for basename 'dmenuhandler'
> Value "/bin/sh" at offset 23 matches at /usr/share/mime/magic line 932
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/vendor_perl/File/MimeInfo/Applications.pm line 140.
Please choose an application

	1) Geany  (geany)
	2) Neovim  (nvim)
	3) Code - OSS  (code-oss)
	4) LibreOffice Writer  (libreoffice-writer)

use application #

As a follow-up to issue #15: If a parent directory name contains a UTF-8 character, mimeopen does not handle this properly.

> mimeopen ä/x.pdf 
Opening "�/x.pdf" with Document Viewer  (application/pdf)

So far, so good - but now for my next trick:

> cd ä
> mimeopen x.pdf 
Opening "x.pdf" with Document Viewer  (application/pdf)

** (xreader:116105): WARNING **: 15:33:57.311: Error when getting information for file “/home/ml/ä/x.pdf”: No such file or directory
[...]

Calling xreader x.pdf within that directory (or with the full path) works correctly.

Full disclosure: I'm not a Perl developer, so I can make wrong assumptions here.
Observed behavior: after setting a default app with mimeopen -d %file%, using mimeopen %file% uses the old app and not the new default.

There are these lines: https://github.com/mbeijen/File-MimeInfo/blob/master/lib/File/MimeInfo/Applications.pm#L103-L105
Now, the user's mimeapps.list goes first there, and that's how it's supposed to be.
But then, the list is reversed for some reason. Hence, _find_file always receives the old apps first.

In Debian we are currently applying the following patch to File-MimeInfo.
We thought you might be interested in it too.

The patch is located at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libfile-mimeinfo-perl.git;a=blob;f=debian/patches/0001-Properly-escape-MIME-types-containing.patch;hb=HEAD

Bug-Debian: http://bugs.debian.org/690334
From 7ae0f8640dde7316b42db4874c9ccc6fed9d7940 Mon Sep 17 00:00:00 2001
From: "brian m. carlson" <[email protected]>
Date: Fri, 31 May 2013 20:06:56 +0000
Subject: [PATCH] Properly escape MIME types containing +.

Previously, MIME types were placed as-is into regular expressions.  This caused
problems for types such as image/svg+xml and breaking mimeopen.  Now the MIME
types are escaped so that they are matched properly.

---
lib/File/MimeInfo/Applications.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/File/MimeInfo/Applications.pm b/lib/File/MimeInfo/Applications.pm
index 645861b..6eea4f0 100644

Thanks in advance,
gregor herrmann, Debian Perl Group

update-desktop-database replaces subdirs separator ("/") with a dash ("-") when building the database.

Like /usr/share/applications/kde4/dolphin.desktop -> kde4-dolphin.desktop

See old discussion here: http://lists.freedesktop.org/archives/xdg/2006-June/006630.html

File-MimeInfo doesn't handle such records. It cannot work with kde4/dolphin.desktop and other desktop files like that.

If we have mimeinfo.cache with:

inode/directory=easytag.desktop;kde4-filelight.desktop;kde4-kfmclient_dir.desktop;kde4-dolphin.desktop;

mimeopen from File-MimeInfo opens inode/directory only with easytag.desktop.

I wanted to upload 0.24 to Fedora, but tests failed:

make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/.t
WARNING: You don't seem to have any mimeinfo.cache files.
Try running the update-desktop-database command. If you
don't have this command you should install the
desktop-file-utils package. This package is available from
http://freedesktop.org/wiki/Software/desktop-file-utils/
t/00_use_ok.t ...... ok
t/01_normal.t ...... ok
t/02_magic.t ....... ok
t/03_rox.t ......... ok
t/04_IO_objects.t .. ok

Failed test 'mime_application() works'

at t/05_more.t line 49.

Failed test 'desktop file is the right one'

at t/05_more.t line 55.

got: undef

expected: 't/applications/mirage.desktop'

Looks like you failed 2 tests of 16.

t/05_more.t ........
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/16 subtests
t/06_pod_ok.t ...... ok
WARNING: You don't seem to have any mimeinfo.cache files.
Try running the update-desktop-database command. If you
don't have this command you should install the
desktop-file-utils package. This package is available from
http://freedesktop.org/wiki/Software/desktop-file-utils/
t/07_pod_cover.t ... ok
t/08_changes.t ..... skipped: Test::CPAN::Changes 0.18 or later required for this test

Test Summary Report

t/05_more.t (Wstat: 512 Tests: 16 Failed: 2)
Failed tests: 13-14
Non-zero exit status: 2
Files=9, Tests=78, 2 wallclock secs ( 0.16 usr 0.02 sys + 1.63 cusr 0.16 csys = 1.97 CPU)
Result: FAIL
Failed 1/9 test programs. 2/78 subtests failed.
make: *** [test_dynamic] Error 255
error: Bad exit status from /var/tmp/rpm-tmp.Z4ReOz (%check)
Bad exit status from /var/tmp/rpm-tmp.Z4ReOz (%check)
RPM build errors:
Child return code was: 1

It seems the file t/applications/mirage.desktop is not part of CPAN tarball.

File::MimeInfo::Applications references http://freedesktop.org/wiki/Software_2fdesktop_2dfile_2dutils twice but appears to no longer exist

When executing the extensions function, while $_ is read-only (in loop context, for example), an exception is thrown.

Example:

#!/usr/bin/env perl

use strict;
use warnings;

use File::MimeInfo qw(extensions);

warn extensions($_) for qw[
    application/x-perl
];

1;

Execution:

hatsuseno@host ~ $ ./test.pl 
Modification of a read-only value attempted at /usr/lib64/perl5/vendor_perl/5.24.1/File/MimeInfo.pm line 237.

Hello,

I found myself writing the same mimetype_really_isa function over and over again, such that I eventually made it into a module of its own (a Role, actually):

https://github.com/doriantaylor/p5-role-mimeinfo/blob/master/lib/Role/MimeInfo.pm#L80

The code changes the behaviour of mimetype_isa the following ways:

• mimetype_isa('a/b', 'a/b') now returns true
• mimetype_isa('a/b.noncanon', 'a/b') now returns true
• mimetype_isa('a/b', 'x/y.noncanon') now returns true (assuming a/b is a x/y to begin with)
• mimetype_isa('a/b') will return the entire set of ancestor types (including a/b and all paths up to application/octet-stream)

The purpose was to create a mimetype_isa that would take as wide a range of input as possible and didn't need any finessing first, which I found myself repeatedly doing with my own ad-hoc mimetype_really_isa function.

So, I wrapped it up into a Role. It really shouldn't be a Role. Indeed the code should probably be in this module.

But, of course, the behaviour is subtly different, so I'm not about to do a fork/clone/PR without talking to you first.

Thoughts?

mimeinfo tries to catch people wrongly passing it a file handle rather than a file name, but in doing so it also blocks reasonable uses of supplying a file name as an object (which stringifies to the name):

$ perl -MPath::Tiny -MFile::MimeInfo -wE 'say mimetype path q[whamm.mp3]'
You should use File::MimeInfo::Magic to check open filehandles at -e line 1.

This thwarts the use of popular modules such as Path::Class and Path::Tiny, used to manipulate paths.

Please can you either remove this check (and presume the caller knows what she's doing) or refine it to let through objects that stringify. Thanks.

The Shared MIME-info Database spec says:

The first glob element represents the "main" extension for the file type. While this doesn’t affect the
mimetype matching algorithm, this information can be useful when a single main extension is needed
for a mimetype, for instance so that applications can choose an appropriate extension when saving a
file.

This is useful information. In particular, it would be good if the extensions() function returned the glob elements in the order defined in each file. The trouble is that the order is randomized in the globs file, if the weights are equal, so for example on my system the extension returned by extensions() in scalar context for applicaton/javascript is .jsm, and not the more obvious .js, which is the first in the XML file, and hence the main extension according to the spec.