"File" looks at file contents, the file name doesn't matter. Someone from the mono team would have to come up with the right magic (man magic) for mono executables and libraries.

At first, this is not a blocker. Then: What should the actual type of these files be? The output looks correct to me. As Andreas already mentioned: file checks for magic numbers and sometimes header-information of the detected type, not the suffix.

In my not-very-technical opinion it should be possible for users to tell the difference between (1) mono files that run natively on Linux and (2) Windows executables and dlls - *without* checking magic numbers or header information.

I foresee a lot of trouble explaining to noobs and non technical people why one *.exe works with Linux and another *.exe doesn't.

What the extension is, is not important, so long as it is not easily confused with other file types or files running on different platforms.

Users never run these binaries manually. So why should they care at all?

Then there is no need to explain this to the user at all. You don't explain to the user why they cannot run HP-UX binaries on Linux, do you? Every user that still has some brain left does easily understand that you cannot run a HP-UX binary on Linux if you just tell him. Why shouldn't he understand the same for a Windows binary?

Java uses to call his class files *.class. This is the very same situation. Do you suggest to remove the ".class" of all *.class files?

Do you really suggest that the fact that we use some technology that was originally brought to market by Microsoft must be hidden from the user? Where is this spirit of the Linux community to just make use of technology if it has proven to show some advantages in a specific situation? Did this completely move now into a group of fundamentalists that have no technological background just crying around about everything that has a word in it they do not like. --- Well then we actually already _reached_ the level of the average Windows user communities...

Is the program a windows or dos program or does it run under Linux? If it runs under Linux, then it should get no extention or another extention that is generaly accepted under Linux.

It is CIL bytecode which is used to have the extension EXE. You can run it on _any_ CLR implementation if you have all required libraries installed.

Java applications also run on Linux. They also have an extension (.class). Logical conclusion: Your statement does not make sense.

Dear Michael,

> At first, this is not a blocker. 

Okay, accepted, it just reflected my state of mind..

> Then: What should the actual type of these
> files be? The output looks correct to me. As Andreas already mentioned: file
> checks for magic numbers and sometimes header-information of the detected 
> type, not the suffix.

Sure, I know these facts, I was simply disgusted about that output:
If we have to accept those suffixes as a convention, as Robert pointed out (and I anticipated), it should be possible to determine the difference between real Windows binaries and Mono binaries, and file is the tool at hand. 

Dear Robert, 
> It is CIL bytecode which is used to have the extension EXE. You can run it 
> on _any_ CLR implementation if you have all required libraries installed.

thanks for this clarification, I haven't heard about this convention. Obviously I hadn't any contact with mono, yet. These insights were enough to keep it like that, since IMHO, it inherits a major disease from the paragon: naming shared libs something.dll leads straight into dll hell.. Funny enough, beagle seems to mix both library types. 

Thanks god, that c#/mono was invented after breaking with the 8.3 filename limit..

I don't even have these files in my installation, only an /usr/lib/zmd/zmd-bin which is typed as ELF executable.

Werner: Could this easily be added to the `file'-command or should this better be reported/requested upstream?

I do not understand. The command file looks at the contents of a file
and determine with the help of /usr/share/misc/magic a matching
byte sequence and the the corresponding file type.  Extensions will
never be mentioned by file.  Without the correct magic byte sequences
I will do nothing.  Reopen only if one can provide the correct magics
for mono executables and note it should be tested. I do not accept
magigs which breaks other magics.

For reassign to mono maintainer

Someone of the mono maintainers has to provide the correct and working
entries for those zen binary files.  After this please reassign back
to the maintainer of the pacakge file (me).

Please provide the requested magic entries for the pacakge file.

Created attachment 74984 [details]
magic change to recognize mono assemblies

Patch for the magic file, apply and recompile it with file -C.

Fixed.