ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I currently have a script that uses the file binary (/usr/bin/file) to retrieve the mime type of a particular video file but in many cases I end up with application/octet-stream. However, if I right click on the file in Nautilus and bring up the Properties dialog I always get the correct mime type so I'm guessing Nautilus is using gnomevfs-info to get this information.
Running gnomevfs-info -s /path/to/video yields me the correct results; e.g. application/x-flash-video (note the -s slow mime flag) but I've got to run my script from a server with no desktop manager installed so running gnomevfs-info is not the ideal solution (although I will go with it if I have to).
Is there any way I can use a more generic command like /usr/bin/file but which will give me more accurate results or else can I update /usr/bin/file's mime db to fix the problem?
gnome uses the gnome-mime-database, kde has it's own mime-types and any decent filer is going to have some sort of system, either based on one of the above or with its' own database or some system for handling different file types using 'file' or otherwise.
You can use shell or awk to compare the files to whichever mime database you like.
Thanks for your reply. I admit I'm clueless about the intricacies of mime type detection and so have been fumbling for a solution for a little while now.
I'm eventual solution has been to go with gnomevfs-info as I know what platforms I will be working on and so am pretty sure the correct commmand will be installed. The only issue here is that while ubuntu requires the --slow-mime flag, CentOS' version of gnomevfs-info doesn't recognize the flag at all. No big deal, I just keep trying to detect the mime type until all my options are exhausted.
Using a combination of gnomevfs-info and awk I retrieve the mime type with the following;
My content type detection woes continue although I'm interested to know more.
While I've managed to detect the content types of video files perfectly with gnomevfs-info I've started running into issues with office documents such as pdf, odt, etc. When I run gnomevfs-info --slow-mime or file -i on files without an extension (in the case of file -i with an extension) I get the following;
odt = application/x-zip (understandable but if you open the file in vim you'll see mimetypeapplication/vnd.oasis.opendocument.text in the header of the file)
msword = application/x-ole-storage or nothing in the case of file -i
However, if I run file without the -i flag I get the correct file type but in human readable form;
odt = OpenDocument Text
msword = Microsoft Office Document
I've grep-ed for these values but cannot find them so I'm wondering how it's able to determine this information and why I get the correct human readable value but the incorrect mime types (e.g. application/msword, application/vnd.oasis.opendocument.text).
I may be barking up the wrong tree, but
are you aware that Open Office files are zipped up tar files?
Yes I am but they are files that are still of type vnd.oasis.opendocument.text.
I probably posted my previous message a little too hastily as upon reading the file man page (I know, I should have done this to start with) I notice that file on it's own uses the /usr/share/file/magic file to (correctly) determine the file type in human readable form (i.e. an odt file is detected as "OpenDocument Text", pdf as "PDF document, version ...", etc). However, when I specify the -i or --mime flag I receive a mime type that does not correspond to the entry in /usr/share/file/magic, that is vnd.oasis.opendocument.text. Rather I get application/x-zip.
I guess what my question should be is;
using the file command why am I getting the incorrect mime type (e.g. OpenDocument Text = application/x-zip) of a correctly determined human readable file type and how do I get the correct mime type (e.g. OpenDocument Text = vnd.oasis.opendocument.text)?
Last edited by haydenyoung; 03-21-2007 at 11:41 PM.