ls colors: почему некоторые из моих шрифтов черные, а другие зеленые в выводе ls

10

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

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

Из другого ответа на AskUbuntu я нашел этот ключ о том, как интерпретировать эти цвета. Я не могу понять, почему .ttf будет исполняемым или почему один набор .ttfs будет распознаваться, а не другой.

Синий: каталог

Зеленый: исполняемый или распознанный файл данных

Небесно-голубой: связанный файл

Желтый с черным фоном: устройство

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

Красный: архивный файл

Эти файлы были загружены на Mac с различных сайтов шрифтов перед загрузкой.

files ls colors executable

— Pranab
источник

5

Конкретные цвета (синий, розовый и т. Д.) Ничего не значат. Вы можете настроить цвета, чтобы быть тем, что вы хотите. linux-sxs.org/housekeeping/lscolors.html Чтобы проверить цвета для вашей конкретной системы, введите $ LS_COLORS

— beardedlinuxgeek

Чтобы прояснить, мое намерение было на самом деле не о цветах как таковых, а о том, чтобы понять, указывает ли это на то, что у меня возникнут какие-либо проблемы с моими скриптами / кодом.

— Пранаб

13

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

* _{Как сказано в комментарии Matteo Italia, который должен быть сохранен, он говорит: « Скорее всего, они были скопированы с тома FAT или NTFS, который не хранит исполняемый бит, поэтому монтируются по умолчанию, так что для всех файлов установлен исполняемый бит» ,}

— B слой
источник

1

В точку. Единственное отличие между обычным файлом, для которого установлен «исполняемый» набор разрешений, и тем, который не установлен, состоит в том, что при попытке запустить файл из командной строки для файла с установленным битом x ОС попытается использовать программу, если любой такой определяется в системе, чтобы открыть этот файл.

— Гнудифф

2

@Pranab нет, для шрифтов не должно быть никакой разницы.

— Гнудифф

1

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

— Гнудифф

1

На самом деле, я бы не стал вводить в заблуждение кого-то, кто не знает иначе, поэтому вот мой оригинальный комментарий минус неправильные биты: Есть разные причины, по которым бит может быть установлен ... если где-то в строке кто-то включает исполняемый бит, то это мог "следить" за файлом вокруг. (Это предполагает, что каждый, кто его копирует, сохраняет эти оригинальные фрагменты.) В любом случае, это практически безвредно.

— B Layer

12

Скорее всего, они были скопированы с тома FAT или NTFS, который не хранит исполняемый бит, поэтому монтируются по умолчанию, чтобы во всех файлах был установлен исполняемый бит .

— Matteo Italia

6

Кажется, что lsкоманда, которую вы выполняете, является псевдонимом дляls --color

человек лс

--color [= WHEN] раскрасить вывод; КОГДА может быть «всегда» (по умолчанию, если опущено), «авто» или «никогда»; больше информации ниже

Вы можете проверить это, запустив origin ls:

Используя цитаты:

"лс" -а
Используя полный путь (например, если lsместоположение находится в /bin/ls) и посмотрите, показывает ли он цвета или нет:

/ bin / ls -a

Примечание: запуск 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 (fat, ntfs и т. Д.), Вероятно, будут отображаться в системе как исполняемые. Перемещение или копирование этих файлов в файловую систему Unix с использованием инструмента, который сохраняет права доступа, сохранит эти исполняемые биты.

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

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

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

— plugwash
источник

2

Как говорилось в предыдущих ответах, раскраска указывает, считаются ли файлы исполняемыми или нет.

Разрешение «выполнить» (= бит) в Linux и большинстве других Unixes имеет одно значение для файлов, а другое - для каталогов.

Для каталогов, если у вас есть разрешение на выполнение, вы можете увидеть его содержимое. Если вы этого не сделаете, вы не сможете перейти в каталог и не можете перечислить в нем файлы, даже если у вас есть права на чтение и запись в каталог.

Для обычных файлов (в отличие от файлов устройств и других специальных типов файлов Unix) бит выполнения означает, что если вы используете имя файла в командной строке, O / S (или, точнее: shell) попытается «выполнить» или запустить файл как команда. И наоборот, если у вас нет разрешения на выполнение файла, вы не можете запустить его из командной строки.

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

Это команды ОС, такие как «cat» и «grep», которые обычно имеют исполняемые файлы в / * / bin / каталогах - / bin, / usr / bin, / sbin, / usr / sbin и т. Д.

Кроме того, могут существовать некомпилированные интерпретируемые сценарии, написанные на каком-либо языке программирования, например Python или сценариях оболочки (в основном, команды, которые вы пишете, как будто из командной строки при подключении к серверу).

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

Это делается оболочкой, пытаясь прочитать первую строку файла и найти нотацию «shebang», какую программу предполагается запустить.

Итак, если ваш foobar был текстовым файлом с первой строкой, подобной этой:

#!/usr/bin/python

Затем shell попытается выполнить команду:, в /usr/bin/python foobarосновном вызывая интерпретатор python и передавая ему имя вашего файла foobar как скрипт Python.

Если оболочка не найдет такую первую строку в вашем файле, она попытается выполнить foobar, как если бы она содержала команды оболочки.

Если файл с исполняемым битом не содержит допустимых команд оболочки, оболочка будет просто жаловаться.

Вот что произойдет, если у вас есть файлы TTF с установленным битом exec и вы пытаетесь запустить его из командной строки:

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

Таким образом, для шрифтов, вероятно, лучше, если бит exec не установлен, но ничего не меняет.

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

$python foobar

вместо того

$./foobar

То же самое с примером системных команд, таких как «cat». Если вы удалите бит exec из «cat», вы все равно можете передать его в новый экземпляр оболочки для выполнения:

$sh -c 'cat myfile'

будет работать, даже если вы удалили бит exec из cat и

$cat myfile

не делает.

— Gnudiff
источник

2

В моей системе, по крайней мере, сначала убрать исполняемый бит на двоичный исполняемый файл , например , catили echoже не позволяет запускать его с помощью sh -c 'cat myfile', ни с system("cat", "myfile")языками , как Ruby. Причина, по которой Python может запускать неисполняемые .pyфайлы, заключается в том, что он считывает их как строку текста, а затем использует интерпретатор, чтобы заставить этот текст вести себя так, как будто это код.

— Итан Камински

@EthanKaminski Интересно. Я отчетливо помню, как это работает для меня, но мне придется проверить детали.

— Гнудифф

1

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

— zwol

Это не оболочка, которая определяет, нужно ли и как извлечь файл, это ядро. Оболочка просто передает имя исполняемого файла и параметры ядру.

— plugwash