Comme indiqué dans les réponses précédentes, la coloration consiste à indiquer si les fichiers sont considérés comme exécutables ou non.
L'autorisation "exécuter" (= bit) sous Linux et la plupart des autres Unix a une signification pour les fichiers et une autre pour les répertoires.
Pour les répertoires, si vous y êtes autorisé à exécuter, vous pouvez voir son contenu. Si vous ne le faites pas, vous ne pouvez pas accéder au répertoire dans le répertoire, ni y lister les fichiers, même si vous disposez d'un accès en lecture et en écriture au répertoire.
Pour les fichiers normaux (par opposition aux fichiers de périphérique et à d'autres types de fichiers Unix spéciaux), le bit d'exécution signifie que si vous utilisez le nom de fichier sur la ligne de commande, le O / S (ou plus précisément: shell) essaiera d'exécuter ou d'exécuter le fichier en tant que commande. Inversement, si vous ne disposez pas de l'autorisation d'exécution sur le fichier, vous ne pouvez pas l'exécuter à partir de la ligne de commande.
Ainsi, si vous, par exemple, supprimez l'autorisation x de tous les utilisateurs du fichier / bin / cat (qui est une commande Unix), vous-même ou quelqu'un d'autre et tout programme qui essaie d'utiliser la commande "cat" échouera.
Ce sont alors les commandes du système d'exploitation, telles que "cat" et "grep", qui ont généralement des fichiers exécutables dans les répertoires / * / bin / - / bin, / usr / bin, / sbin, / usr / sbin etc.
Et puis il peut y avoir des scripts interprétés non compilés, qui sont soit écrits dans certains langages de programmation, tels que Python ou des scripts shell (en gros, les commandes que vous écrivez comme si à partir de la ligne de commande lors de la transmission au serveur).
Maintenant, lorsque vous définissez le bit d'exécution sur le fichier de script (par exemple, le fichier foobar) et essayez de l'exécuter par votre shell: "./foobar", le shell essaie d'analyser le fichier et de trouver le programme approprié pour passer le script à.
Le shell le fait en essayant de lire la première ligne du fichier et en trouvant la notation "shebang" du programme que cela est censé exécuter.
Donc, si votre foobar était un fichier texte avec la première ligne comme ceci:
#!/usr/bin/python
Ensuite, le shell essaierait d'exécuter la commande /usr/bin/python foobar:, invoquant essentiellement l'interpréteur python et lui passant le nom de votre fichier foobar en tant que script Python.
Si shell ne trouve pas une telle première ligne dans votre fichier, il essaiera alors d'exécuter foobar lui-même comme s'il contenait des commandes shell.
Si le fichier avec un bit exécutable ne contient pas de commandes shell valides, le shell se plaindra simplement.
C'est donc ce qui se passerait, si vous avez des fichiers TTF avec un bit exécutable défini et que vous essayez de l'exécuter à partir de la ligne de commande:
$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$
Donc, pour les polices, c'est probablement plus propre, si le bit exec n'est pas défini, mais ne change vraiment rien.
PS Juste quelques informations superflues. Si vous supprimez le bit d'exécution d'une commande ou d'un script, il peut toujours être transmis à tout autre programme en tant qu'argument. Si cet autre programme sait comment exécuter votre commande, la suppression du bit d'exécution n'a pas vraiment d'importance. Par exemple, le script foobar Python serait toujours exécuté par l'interpréteur Python, si vous le faisiez simplement à partir de la ligne de commande:
$python foobar
au lieu de
$./foobar
Idem avec l'exemple des commandes système, telles que "cat". Si vous supprimez le bit d'exécution de "cat", vous pouvez toujours le passer à une nouvelle instance de shell pour exécution:
$sh -c 'cat myfile'
fonctionnera, même si vous avez supprimé le bit d'exécution de cat et
$cat myfile
non.
