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.

hi gnashley

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;

Not sure if my awk is completely correct but seems to work okay.

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?

Hi bigearsbilly

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)?