Presumably that's the file browswer from LXDE, PCMan, and it is just being literal when it says a file is executable.
"Executable" on Unix style systems refers to a permission mode set on a file, as opposed to an intrinsic, abstract quality of the file content (which is what you perhaps were expecting). For example:
chmod a+x foobar
The new, empty (zero size) file
foobar now has the exectuable bit set for all users (see
man chmod). If instead you used
chmod o+x foobar, it would only have that set for the owner; it would not be executable for other non-privileged users.
There are a few reasons for this pragmatic conception of "executable":
- Security: Files can be set as not necessarily executable by anyone. This clarifies the concept of executable as being about permissions, and not a more technical abstract quality of the content. Just because you have permission to execute something does not mean it will ultimately work, and just because it might ultimately work does not mean it will for someone who doesn't have permission.
- Files such as shell or python scripts, which are not compiled binaries with an entry point, (i.e., are not truly executable in a more abstract technical sense, what might be tagged
.exe files on DOS derived systems1), but which can be executed by a system interpreter, can be marked as executable.
Note that the "technical, abstract quality" people may think of as executable is not obvious without examining a file's content, and even then is not guaranteed without actually trying it -- something it no filebrowser anywhere should/would do because it represents a serious security risk. Just because you plug a USB stick into a computer does not mean you want the OS to try and execute every file which claims to be executable, in order to tell you later for sure whether it is or not.
Further, that that abstract quality we may think of is still not what we often really mean by "executable", or at least would like our file browser to recognize as such (so it will, e.g., include scripts), even if we don't understand this distinction, which is why the permission mode is normally more of a pragmatic indicator.
In this case, as other people have pointed out, the reason that file won't execute is because it's not in the right format for the operating system. What happens when you try to do so depends on how you try to do -- processes are always children of other processes, and it is up to the parent, in this case PCMan, to do stuff like resolve any errors and report them to the user. However, it may have other priorities that account for why it won't always do so.
You can usually get a clue by running
file on the file, which examines its content for indications of what the file is for.
file $(which file)
file on itself, and on a Pi 2 will probably yield something starting
/usr/bin/file: ELF 32-bit LSB executable, ARM, .... On a 32-bit ARM system running linux such a file could truly be executable (but the only way to tell if it really is to try it).
The output from
file on that
eclipse most likely has the
ARM replaced with
x86-64 if it is also
ELF 64-bit). The reason the file browser doesn't scan everything this way is that permission modes are the more normative methodology, and what someone experienced with the OS would expect it to report.
1. Using an
.exe suffix is not really evidence that a file is executable either, although much like the permission bit in a *nix system, a DOS-esque OS may take it to mean that. You could copy that
foobar file to a windows box, rename it
foobar.exe, and the system will probably believe you even if actually executing the file will do nothing.