Bug 12488

Summary: Scripts subclass application/x-executable
Product: shared-mime-info Reporter: Yevgen Muntyan <muntyan>
Component: freedesktop.org.xmlAssignee: Jonathan Blandford <jrb>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Yevgen Muntyan 2007-09-19 10:33:13 UTC 
Bunch of mime types (application/x-awk, application/x-perl, application/x-python and others) are subclasses of application/x-executable. But it doesn't make sense, since the application/x-executable is a type for binary executable files. It would make sense if application/x-executable was in fact some application/x-can-be-executed-in-some-way, but not now. For example, a python source file is not an executable, it's executable only if you add the shebang line. It's not something "magically" executable, as "real" binaries are. 

More importantly, subclassing is broken here if you look at "what the heck this file is and what to do about it". What you do with a script (execute or open in a text editor) is totally different from what you do with a binary (execute or maybe open in a hex editor for power hackers).

It should be solved by adding a text/x-script mime type, and make all those scripts subclass it. It may or may not be a subclass of some "executable" mime type, but certainly not a subclass of the mime type which describes "binary executable files" (and matches magic ELF or whatever signatures).

Note that the spec says this (Subclassing section):
"Subclassing is about the format, rather than the catagory of the data (for example, there is no 'generic spreadsheet' class that all spreadsheets inherit from)."
So making scripts subclass application/x-executable is wrong again. (I don't quite understand that paragraph, and think it only reduces usability of the spec, but it's what we got)

A practical consequence of this bug here is: after icon theme upgrade all scripts look like binaries in the text editor. It's not the mime spec fault of course, it's the problem that icon theme spec doesn't say how to find icons for mime types. But, to work it around, I have to understand how to treat mime types, e.g. in this particular case I should look at all parent classes of given mime type and somehow decide which one is "nicer". And this is where mime spec plays its role. Or rather it doesn't tell me anything about this situation, and explicitly tells it's not its business. But then all we got is mime types, and having yet-another classification for file types would be stupid.
Comment 1 Bastien Nocera 2009-04-20 10:43:28 UTC 
Why do you think that "application/x-executable" doesn't represent "files that can be executed in some way"?

Sorry, I don't see what problems this could cause, apart from the missing icon, something which is fixed by the use of the "generic-icon" in recent specs, and the fact that those script types are usually sub-classes of "text/plain" as well.

File a bug against your file manager if it still shows a "binary" icon for a python file, instead of a "text" icon.
Comment 2 Yevgen Muntyan 2009-04-20 21:48:17 UTC 
Well, I'll quote for instance this: "It may or may not be a subclass of some "executable" mime
type, but certainly not a subclass of the mime type which describes "binary
executable files" (and matches magic ELF or whatever signatures).
"
But whatever, this more than a year old bug is what it is, an ancient bug which was worked around long time ago. Note that I was the author of "your file manager" so I couldn't file a bug report back then.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.