Compatibility with file(1)?
nirvdrum opened this issue · 1 comments
I apologize for this being more of a question than a bug report, but I've noticed some incompatibilities with the file(1) command. I don't know enough about where the two are sourcing their MIME data from, but I'd have expected one to be a subset of the other. As an example, file will report "text/x-ruby" for a Ruby source file, while this project only honors "application/x-ruby".
Is this something that should be fixed in one of the two projects? Or is this something that I should just build up my own database locally with MIME::Types#add?
These projects are orthogonal to each other. The data for this is found in mime-types/mime-types-data, which is sourced primarily from the IANA MIME content registry. This doesn’t include a lot of extensions, and no magic data (as used in file(1)).
If you wish Ruby source files to be recognized additionally as text/x-ruby, a pull request to mime-types-data is appropriate (just modify the appropriate YAML file) and the next data release will include it.
I see no reason not to include the data from file(1), but currently don’t have a parser written for it as tooling in mime-types-data. If it were to be added, it would be imperative that it be able to pull from one or more well-known locations on the Internet so that different magic files can be parsed for various different operating systems. The same applies to the Gnome MIME registry file.
If we wanted to do magic byte detection (like file(1)), that would need to be a new Gem (mime-type-file) that perhaps uses mime-types-data as its data source. I’d be happy to add a successful project to this organization, but won’t be implementing such myself—I don’t have a need for it.