ls colors: por que algumas das minhas fontes são pretas e outras verdes na saída ls

Question

Enviei alguns arquivos de fontes para o AWS (executando o Amazon Linux) e movi-os para o diretório /usr/share/fonts usando o comando cp em .ebextensions.

Quando faço SSH no meu mac e uso ls -a , vejo alguns arquivos com cores diferentes - um conjunto de arquivos de fonte é preto, enquanto outros são verdes. Estou curioso para saber o que causou isso e se isso criará algum problema para o meu código .

De outra resposta no AskUbuntu eu encontrei esta chave sobre como interpretar essas cores. Não consigo entender porque um .ttf seria executável ou porque um conjunto de .ttfs seria reconhecido e não outro.

Blue: Directory

Green: Executable or recognized data file

Sky Blue: Linked file

Yellow with black background: Device

Pink: Graphic image file

Red: Archive file

Esses arquivos foram todos baixados para um mac de vários sites de fontes antes de serem enviados.

    

Answer 1

ls -l dirá a você definitivamente se um arquivo é executável ou não. Eu não acho que haja algum grande mistério aqui. Você baixou arquivos de várias fontes, cada um dos quais pode ter diferentes bits de permissão definidos (sem nenhuma razão específica). Se você não gosta de ver alguns com cores e outros sem tentar chmod -x *.ttf ... arquivos de fonte não devem precisar do conjunto de bits executável.

    

Answer 2

Parece que o comando ls que você está executando é um alias para ls --color

man ls

--color[=WHEN] colorize the output; WHEN can be 'always' (default if omitted), 'auto', or 'never'; more info below

Você pode verificar isso executando a origem ls :

• Usando aspas:

  "ls" -a

• Usando o caminho completo (por exemplo, se ls location está em /bin/ls ) e veja se mostra as cores ou não:

  / bin / ls -a

Observação: executar ls -la mostrará os detalhes dos arquivos e você poderá ver todos os detalhes de cada arquivo, o que permitirá que você verifique com a saída esperada de ls --color

    

Answer 3

A cor indica que o arquivo está marcado como "executável" *

Os bits de permissão do executável (um para o usuário, um para o grupo, um para o outro) significa que se o nome do arquivo for passado para uma das chamadas do sistema exec, o kernel irá adiante e tentará excluí-lo.

A convenção é que somente os arquivos que são realmente destinados a serem executados têm o bit executável definido. No entanto, ao mover / copiar arquivos, especialmente em um ambiente multiplataforma, é fácil obter ou perder inadvertidamente os bits executáveis.

Os arquivos armazenados em um sistema de arquivos que não suporta permissões unix (fat, ntfs, etc.) provavelmente aparecerão no sistema como executáveis. Mover ou copiar esses arquivos para um sistema de arquivos unix usando uma ferramenta que preserva as permissões preservará esses bits executáveis.

Por outro lado, o uso de ferramentas para mover arquivos que não podem preservar permissões ou são usados com a opção de preservar as permissões desmarcadas provavelmente resultará na cópia não marcada como executável, mesmo que o original tenha sido.

Então, depois de ser movido por uma variedade de plataformas usando uma variedade de ferramentas, os bits de permissão executáveis podem acabar em um estado bastante arbitrário.

* Não tenho 100% de certeza de como ls lida com o caso em que alguns, mas não todos, os bits executáveis são definidos.

    

Answer 4

Como as respostas anteriores disseram, a coloração serve para indicar se os arquivos são considerados executáveis ou não.

A permissão "executar" (= bit) no Linux e na maioria dos outros Unixes tem um significado para os arquivos e outro para os diretórios.

Para diretórios, se você tiver permissão de execução, poderá ver seu conteúdo. Se você não fizer isso, não poderá fazer o cd para o diretório, nem poderá listar arquivos nele, mesmo se tiver acesso de leitura e gravação ao diretório.

Para arquivos regulares (ao contrário de arquivos de dispositivos 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 O / S (ou mais precisamente: shell) tentará "executar "ou execute 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 a partir da 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 tente usar o comando "cat" falhará.

Esses são, então, os comandos do sistema operacional, 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 não compilados e interpretados, que são escritos em alguma linguagem de programação, como Python ou shell scripts (basicamente, comandos que você escreve como se de uma linha de comando ao sshing para um servidor).

Agora, quando você definir o bit de execução no arquivo de script (por exemplo, arquivo foobar) e tentar executá-lo pelo seu shell: "./foobar", o shell tentará analisar o arquivo e localizar o programa correto. passe o script para.

Isso ocorre quando o shell tenta ler a primeira linha do arquivo e encontrar a notação "shebang" qual programa isso deve rodar.

Então, se o seu foobar era um arquivo de texto com a primeira linha assim:

#!/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 encontrasse essa primeira linha em seu arquivo, ele tentaria executar o foobar como se contivesse comandos shell.

Se o arquivo com bit executável não contiver comandos shell válidos, o shell simplesmente iria reclamar.

Então, isso é o que aconteceria se você tivesse arquivos TTF com exec bit set e tentasse executá-los a partir da linha de comando:

$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$

Portanto, para fontes, é provavelmente mais simples, se o bit exec não estiver definido, mas realmente não muda nada.

P.S. Apenas alguma informação estranha. Se você remover o bit de execução em algum comando ou script, ele ainda pode ser passado para qualquer outro programa como um argumento. Se esse outro programa sabe, como executar o seu comando, a sua remoção do bit exec realmente não importa. Por exemplo, o script foobar do foobar ainda seria executado pelo interpretador Python, se você simplesmente fizesse da linha de comando:

$python foobar

em vez de

$./foobar

Mesmo 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 que você tenha removido o exec bit do cat e

$cat myfile

não.