Como as respostas anteriores disseram, a coloração é para indicar se os arquivos são considerados executáveis ou não.
A permissão "execute" (= bit) no Linux e na maioria dos outros Unixes tem um significado para arquivos e outro para diretórios.
Para diretórios, se você tiver permissão para executar, poderá ver seu conteúdo. Caso contrário, não será possível fazer o cd no diretório nem listar arquivos nele, mesmo que você tenha acesso de leitura e gravação ao diretório.
Para arquivos regulares (ao contrário dos arquivos de dispositivo e outros tipos especiais de arquivos Unix), o bit de execução significa que, se você usar o nome do arquivo na linha de comando, o sistema operacional (ou mais precisamente: shell) tentará "executar" ou executar o arquivo como um comando. Por outro lado, se você não tiver permissão de execução no arquivo, não poderá executá-lo na linha de comando.
Portanto, se você, por exemplo, remover a permissão x de todos os usuários no arquivo / bin / cat (que é um comando Unix), você ou qualquer outra pessoa e qualquer programa que tentar usar o comando "cat" falhará.
Esses são os comandos do SO, como "cat" e "grep", que possuem arquivos executáveis normalmente em / * / bin / diretórios - / bin, / usr / bin, / sbin, / usr / sbin etc.
E então pode haver scripts interpretados não compilados, que são escritos em alguma linguagem de programação, como Python ou shell scripts (basicamente, comandos que você escreve como se fossem da linha de comando quando estiver no servidor).
Agora, quando você define o bit de execução no arquivo de script (por exemplo, arquivo foobar) e tenta executá-lo pelo seu shell: "./foobar", o shell tenta analisar o arquivo e encontrar o programa correto para passar o script para.
Isso é feito pelo shell, tentando ler a primeira linha do arquivo e localizando a notação "shebang" de qual programa ele deve executar.
Portanto, se o seu foobar era um arquivo de texto com a primeira linha como esta:
#!/usr/bin/python
Então o shell tentaria executar o comando /usr/bin/python foobar:, basicamente invocando o interpretador python e passando o nome do seu arquivo foobar para ele como um script Python.
Se o shell não encontrar essa primeira linha no seu arquivo, ele tentará executar o próprio foobar como se contivesse comandos do shell.
Se o arquivo com bit executável não contiver comandos válidos do shell, o shell simplesmente reclamará.
Então é isso que aconteceria, se você tiver arquivos TTF com o bit exec definido e tentar executá-lo na linha de comando:
$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$
Portanto, para fontes, é provavelmente mais limpo, se o bit exec não estiver definido, mas realmente não mudar nada.
PS Apenas algumas informações estranhas. Se você remover o bit de execução em algum comando ou script, ele ainda poderá ser passado para qualquer outro programa como argumento. Se esse outro programa sabe, como executar seu comando, sua remoção do bit exec realmente não importa. Por exemplo, o script foobar Python ainda seria executado pelo interpretador Python, se você simplesmente fizesse na linha de comando:
$python foobar
ao invés de
$./foobar
O mesmo acontece com o exemplo dos comandos do sistema, como "cat". Se você remover o bit exec de "cat", ainda poderá passá-lo para uma nova instância do shell para execução:
$sh -c 'cat myfile'
funcionará, mesmo se você tiver removido o bit exec do gato e
$cat myfile
não.
