ls color: чому деякі з моїх шрифтів чорні, а інші - зелені


10

Я завантажив кілька файлів шрифтів у AWS (працює на Amazon Linux) і перемістив їх до /usr/share/fontsкаталогу за допомогою cpкоманди в .ebextensions.

Коли я входжу в SSH від свого комп'ютера та використовую ls -a, я бачу, що деякі файли пофарбовані по-різному - один набір файлів шрифтів чорний, а інші - зеленого кольору. Мені цікаво, що стало причиною цього, і якщо це створить якісь проблеми для мого коду .

каталог шрифтів на Elastic Beanstalk під управлінням AWS Linux

ls -ла скріншот

З іншої відповіді на AskUbuntu я знайшов цю клавішу про те, як інтерпретувати ці кольори. Я не можу зрозуміти, чому .ttf буде виконуваним або чому один набір .ttfs буде розпізнаний, а не інший.

Синій: Довідник

Зелений: Виконаний або розпізнаний файл даних

Небесно-синій: пов'язаний файл

Жовтий з чорним фоном: Пристрій

Рожевий: файл графічного зображення

Червоний: Архівний файл

Ці файли перед завантаженням завантажувались на mac з різних шрифтових сайтів.


5
Конкретні кольори (синій, рожевий тощо) нічого не означають. Ви можете налаштувати кольори таким, яким ви хочете. linux-sxs.org/housekeeping/lscolors.html Щоб перевірити кольори для вашої конкретної системи,
відлучіть

Для уточнення, моя мета не була насправді щодо кольорів як такої, але щоб зрозуміти, якщо це вказує, я зіткнуся з будь-якими проблемами зі своїми сценаріями / кодом.
Пранаб

Відповіді:


13

ls -lостаточно скаже вам, чи файл виконується чи ні. Я не думаю, що тут є якась велика таємниця. Ви завантажили файли з різних джерел, у кожному з яких могли бути різні біти дозволів з тих чи інших причин. * Якщо вам не подобається бачити деякі з кольорами та інші без спроб chmod -x *.ttf... файли шрифтів не повинні потребувати встановленого біту.

* Як говориться в висококваліфікованому коментарі Маттео Італії, який слід зберегти: Найімовірніше, вони були скопійовані з тома FAT або NTFS, які не зберігають виконуваний біт, тому монтуються за замовчуванням, щоб усі файли встановили виконувану біт .


1
Саме так. Єдина відмінність між звичайним файлом, який має набір 'дозволених' дозволів, і тим, що його немає, полягає в тому, що коли ви намагаєтеся запустити файл з командного рядка, для файлу з набором біт x ОС буде намагатися використовувати програму, якщо будь-яке таке визначено в системі, щоб відкрити цей файл.
Gnudiff

2
@Pranab ні, для шрифтів не повинно бути різниці.
Gnudiff

1
@Pranab Рада, що можу допомогти. Коли я перебуваю на належному комп’ютері з клавіатурою, я спробую зробити трохи більш інформативну відповідь, щоб був доступний ширший контекст.
Gnudiff

1
Насправді я б не ввів в оману того, хто не знає інакше, тому ось мій оригінальний коментар мінус неправильні біти: Є різні причини, чому біт може бути встановлений. Якщо де-небудь по лінії хтось вмикає виконуваний біт, то це може "стежити" за файлом навколо. (Це передбачає, що кожна людина, яка копіює її, зберігає ці оригінальні шматочки.) Це в значній мірі нешкідливе.
B Layer

12
Швидше за все, вони були скопійовані з тома FAT або NTFS, які не зберігають виконуваний біт, тому монтуються за замовчуванням, щоб усі файли встановили виконуваний біт .
Маттео Італія

6

Схоже, lsкоманда, яку ви виконуєте, є псевдонімомls --color

людина лс

--кольоровий [= КОЛИ] розфарбувати вихід; КОЛИ можуть бути "завжди" (за замовчуванням, якщо пропущено), "авто" або "ніколи"; більше інформації нижче

Ви можете перевірити це, запустивши походження ls:

  • Використання лапок:

    "лс" -а

  • Використовуючи повний шлях (наприклад, якщо lsмісцезнаходження знаходиться /bin/ls) та побачите, чи він показує кольори чи ні:

    / бін / лс -а

Примітка: запуск ls -laпокаже вам подробиці файлів, і ви зможете побачити повну інформацію про кожен файл, що дозволить вам перевірити очікуваний вихідls --color


Цікаво, скільки способів дійти до основної команди. Мені не було відомо про метод оточення з цитатами. Принаймні з bash, можна також передувати команді з зворотним косою рисою \ls -a, або використовувати вбудовану команду ' command ls -a. Якщо ви хочете побачити, як команда вирішує, а не запускати її, є type -a ls.
B Layer

@BlairM. методи цитат та зворотної косої риси лише запобігають розширенню псевдоніму. Вони не матимуть ніякого ефекту, якщо у вас функція оболонки або вбудована функція ls.
shadowtalker

@ssdecontrol Праворуч. Я не мав на увазі запропонувати інакше ... ми говорили про псевдоніми стосовно ls. Але це гарна інформація.
B Layer

4

Колір означає, що файл позначений як "виконуваний файл" *

Виконані біти дозволів (один для користувача, один для групи, один для інших) означає, що якщо ім'я файлу буде передано одному із системних викликів exec, ядро ​​піде вперед і спробує виконати його.

Конвенція полягає в тому, що лише файли, які насправді призначені для виконання, мають встановлений виконуваний біт. Однак при переміщенні / копіюванні файлів навколо, особливо в мультиплатформенному середовищі, легко випадково отримати або втратити виконувані біти.

Файли, що зберігаються у файловій системі, яка не підтримує права Unix (жир, ntfs тощо), швидше за все, відображатимуться в системі як виконувані. Переміщення або копіювання цих файлів у файлову систему unix за допомогою інструменту, що зберігає дозволи, збереже ці виконувані біти.

З іншого боку, використання інструментів для переміщення файлів, які або не можуть зберегти дозволи, або використовуються з можливістю збереження відмінених дозволів, швидше за все, призведе до того, що копія не буде позначена як виконана, навіть незважаючи на те, що оригінал був.

Тож після переміщення по різних платформах з використанням різноманітних інструментів виконувані біти дозволів можуть закінчитися у досить довільному стані.

* Я не на 100% впевнений, як ls обробляє той випадок, коли встановлені деякі, але не всі виконувані біти.


2

Як було сказано в попередніх відповідях, забарвлення полягає у тому, щоб вказати, чи вважаються файли виконаними чи ні.

Дозвіл "Execute" (= біт) в Linux та більшості інших Unixes має одне значення для файлів та інше для каталогів.

Для каталогів, якщо ви виконали дозвіл на нього, ви можете побачити його вміст. Якщо ви цього не зробите, ви не можете записати компакт-диски до каталогу, а також не можете перераховувати файли в ньому, навіть якщо у вас є доступ і для читання, і для запису.

Для звичайних файлів (на відміну від файлів пристрою та інших спеціальних типів файлів Unix) біт виконання означає, що якщо ви використовуєте ім'я файлу в командному рядку, O / S (а точніше: оболонка) спробує "виконати" або запустити файл як команда. І навпаки, якщо у вас немає дозволу на виконання файлу, ви не можете запустити його з командного рядка.

Отже, якщо ви, наприклад, видалите дозвіл x у всіх користувачів файлу / bin / cat (що є командою Unix), ви самі або будь-хто інший і будь-яка програма, яка намагається використовувати команду "cat", не вдасться.

Це команди OS, такі як "cat" та "grep", які виконують файли, що виконуються, зазвичай в / * / bin / каталоги - / bin, / usr / bin, / sbin, / usr / sbin тощо.

І тоді можуть бути некомпільовані, інтерпретовані сценарії, написані або якоюсь мовою програмування, наприклад, Python або скриптами оболонки (в основному, команди, які ви записуєте так, ніби з командного рядка під час передачі на сервер).

Тепер, коли ви встановлюєте біт виконання файлу сценарію (наприклад, файл foobar), і намагаєтеся виконати його вашою оболонкою: "./foobar", оболонка намагається проаналізувати файл і знайти правильну програму для передачі скрипту до.

Ця оболонка робить, намагаючись прочитати перший рядок файлу і знайшовши позначення "shebang", яка програма повинна запускатися.

Отже, якщо ваш foobar був текстовим файлом із таким же першим рядком:

#!/usr/bin/python

Тоді оболонка намагатиметься виконати команду:, в /usr/bin/python foobarосновному викликаючи інтерпретатора python і передаючи ім'я вашого файлу foobar як сценарій Python.

Якщо shell не знайде такого першого рядка у вашому файлі, то він спробує сам виконати foobar, як якщо б він містив команди оболонки.

Якщо файл з виконуваним бітом не містить дійсних команд оболонки, оболонка просто скаржиться.

Так ось що трапилося б, якщо у вас є файли TTF з бітом exec і намагаєтеся запустити його з командного рядка:

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

Отже, для шрифтів це, мабуть, акуратніше, якщо біт exec не встановлений, але насправді нічого не змінює.

PS Просто деякі сторонні відомості. Якщо ви видалите біт виконання з якоїсь команди чи скрипту, він все одно може бути переданий будь-якій іншій програмі як аргумент. Якщо інша програма знає, як виконати свою команду, ваше видалення біта exec насправді не мало значення. Наприклад, сценарій foobar Python все ще буде виконуватися інтерпретатором Python, якби ви просто зробили це з командного рядка:

$python foobar

замість

$./foobar

Те саме з прикладом системних команд, таких як "кішка". Якщо ви видалите біт exec з "cat", ви все одно можете передати його в новий екземпляр оболонки для виконання:

$sh -c 'cat myfile'

буде працювати, навіть якщо ви видалили exec біт з кота та

$cat myfile

не робить.


2
У моїй системі, по крайней мере, спочатку прибрати виконуваний біт на двійковий виконуваний файл , наприклад , catабо echoж НЕ дозволяє запускати його з допомогою sh -c 'cat myfile', ні з system("cat", "myfile")мовами , як Ruby. Причина, по якій Python може запускати невиконані .pyфайли, полягає в тому, що він читає їх у вигляді текстового рядка, а потім використовує інтерпретатор, щоб змусити цей текст поводитись так, ніби це код.
Етан Камінський

@EthanKaminski Цікаво. Я чітко пам’ятаю, як це працювало на мене, але доведеться перевірити деталі.
Gnudiff

1
@Gnudiff Для двійкових виконуваних файлів execveсистемний виклик наполягає на дозволі на виконання. У системах на основі glibc ви можете викликати динамічний лінкер як програму, щоб отримати приблизно такий же ефект, як і рядок shebang ( /lib64/ld-linux-x86-64.so.2 /bin/cat), і це працює для мене, навіть якщо файл у командному рядку не виконується, але sh -c catце не буде робити для вас.
zwol

Це не оболонка, яка визначає, чи і як виконати файл, це ядро. Оболонка просто передає ім'я виконуваного файлу та параметри ядра.
підключення
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.