I have a number of files showing up green when I run ls. I understand these are executables, and I understand that one can make a file executable with chmod. But they are .csv and .pdf files. I don't understand how one could 'execute' a comma-separated text file or a PDF. So:
This is just a question of permissions. If a file has execute permissions, that just means users are allowed to execute it. Whether they will be successful is another matter. In order for a file to be executed, the user executing it must have the right to do so and the file needs to be a valid executable. The permissions shown by ls only affect the first part, permission, and have no bearing on the rest.
For instance:
$ cat file.csv
a,silly,file
$ chmod a+x file.csv
$ ls -l file.csv
-rwxr-xr-x 1 terdon terdon 13 May 29 15:22 file.csv
This file now has execute permissions (see the 3 x in the permissions string -rwxr-xr-x). But if I try to execute it, I will get an error:
$ ./file.csv
./file.csv: line 1: a,silly,file: command not found
That is because the shell is trying to execute the file as a shell script, and there are no valid shell commands in it, so it fails.
sh interpreter to interpret that file, and that sh interpreter succeeded at interpreting that file (interpreting all the lines in that file as shs do interpret and run code as they read it) as it was in valid sh syntax, but it failed to find the a,silly,file command. As that was the only line in that file, the exit status was 127, so a failure exit status.
Commented
May 29, 2020 at 16:01
The green in your ls display means that the files have execute permissions, which doesn't necessarily mean that they can be executed in any way.
If you accidentally set the execute permission, or if it was set due to an import from a file system without support for the basic linux permission model, you can remove the execute bit with
chmod a-x -- "$filename"
and that file will no longer show as "executable".
Note that other colors in the file listing may be set based on file extension; but in this case it is likely just the permission bits.
The accepted answer perpetuates myths and a poor understanding of how "executing" a file happens in Unix.
./cmd in the shell does more than just trying to execute ./cmd: if executing ./cmd fails with ENOEXEC (as it does for any executable file which is not a valid binary or doesn't start with a shebang, including a valid shell script) then the shell will either a. read and interpret itself the file as a shell script or b. execute /bin/sh or another shell and pass it ./cmd as its first argument.
The shebang mechanism (#! /path/to/interpreter), though implemented by most Unix systems, is not standard. Also, many systems like Linux are also able to "execute" files starting with other "magic" sequences (or even based on their file extension, MSDOS-like).
For instance, you can have "executable" pdf files on Linux via binfmt_misc:
$ chmod +x 2503.pdf
$ ./2503.pdf
./2503.pdf: line 1: fg: no job control
./2503.pdf: line 1051: warning: here-document at line 2 delimited by end-of-file (wanted `/Linearized')
[... a lot of crazy errors in the same vein ...]
$ su -c 'echo :pdf-zathura:M::%PDF-1.::/usr/bin/zathura: > /proc/sys/fs/binfmt_misc/register'
$ ./2503.pdf
[start zathura and display the pdf file]