Я загрузил некоторые файлы шрифтов в AWS (под управлением Amazon Linux) и переместил их в /usr/share/fontsкаталог с помощью cpкоманды в .ebextensions.
Когда я запускаю SSH с моего Mac и использую ls -a, я вижу, что некоторые файлы окрашены по-разному - один набор файлов шрифтов черный, а другие зеленые. Мне любопытно, что послужило причиной этого, и если это создаст какие-либо проблемы для моего кода .
Из другого ответа на AskUbuntu я нашел этот ключ о том, как интерпретировать эти цвета. Я не могу понять, почему .ttf будет исполняемым или почему один набор .ttfs будет распознаваться, а не другой.
Синий: каталог
Зеленый: исполняемый или распознанный файл данных
Небесно-голубой: связанный файл
Желтый с черным фоном: устройство
Розовый: файл графического изображения
Красный: архивный файл
Эти файлы были загружены на Mac с различных сайтов шрифтов перед загрузкой.
источник
Ответы:
ls -lопределенно скажет вам, является ли файл исполняемым или нет. Я не думаю, что здесь есть какая-то великая тайна. Вы загрузили файлы из разных источников, каждый из которых мог иметь разные биты прав доступа по той или иной причине. * Если вам не нравится видеть некоторые с цветами, а другие без попыткиchmod -x *.ttf... файлам шрифтов не нужно устанавливать исполняемый бит.* Как сказано в комментарии Matteo Italia, который должен быть сохранен, он говорит: « Скорее всего, они были скопированы с тома FAT или NTFS, который не хранит исполняемый бит, поэтому монтируются по умолчанию, так что для всех файлов установлен исполняемый бит» ,
источник
Кажется, что
lsкоманда, которую вы выполняете, является псевдонимом дляls --colorВы можете проверить это, запустив origin
ls:Используя цитаты:
"лс" -а
Используя полный путь (например, если
lsместоположение находится в/bin/ls) и посмотрите, показывает ли он цвета или нет:/ bin / ls -a
Примечание: запуск
ls -laпокажет вам подробную информацию о файлах, и вы сможете увидеть полную информацию о каждом файле, что позволит вам проверить с ожидаемым выводомls --colorисточник
\ls -aили использовать встроенную командуcommand ls -a. Если вы хотите увидеть, как команда разрешает, а не запускать, естьtype -a ls.ls.ls. Но это хорошая информация.Цвет указывает, что файл помечен как «исполняемый» *
Биты разрешений исполняемого файла (один для пользователя, один для группы, один для другого) означает, что если имя файла передается одному из системных вызовов exec, ядро пойдет дальше и попытается выполнить его.
Соглашение состоит в том, что только для файлов, которые фактически предназначены для использования, установлен исполняемый бит. Однако при перемещении / копировании файлов, особенно в многоплатформенной среде, легко случайно получить или потерять исполняемые биты.
Файлы, хранящиеся в файловой системе, которая не поддерживает разрешения Unix (fat, ntfs и т. Д.), Вероятно, будут отображаться в системе как исполняемые. Перемещение или копирование этих файлов в файловую систему Unix с использованием инструмента, который сохраняет права доступа, сохранит эти исполняемые биты.
С другой стороны, использование инструментов для перемещения файлов, которые либо не могут сохранять разрешения, либо используются с опцией сохранения отмененных разрешений, может привести к тому, что копия не будет помечена как исполняемая, даже если оригинал был.
Таким образом, после перемещения по различным платформам с использованием различных инструментов исполняемые биты разрешений могут оказаться в довольно произвольном состоянии.
* Я не уверен на 100%, как ls обрабатывает случай, когда установлены некоторые, но не все исполняемые биты.
источник
Как говорилось в предыдущих ответах, раскраска указывает, считаются ли файлы исполняемыми или нет.
Разрешение «выполнить» (= бит) в 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 был текстовым файлом с первой строкой, подобной этой:
Затем shell попытается выполнить команду:, в
/usr/bin/python foobarосновном вызывая интерпретатор python и передавая ему имя вашего файла foobar как скрипт Python.Если оболочка не найдет такую первую строку в вашем файле, она попытается выполнить foobar, как если бы она содержала команды оболочки.
Если файл с исполняемым битом не содержит допустимых команд оболочки, оболочка будет просто жаловаться.
Вот что произойдет, если у вас есть файлы TTF с установленным битом exec и вы пытаетесь запустить его из командной строки:
Таким образом, для шрифтов, вероятно, лучше, если бит exec не установлен, но ничего не меняет.
PS Просто посторонняя информация. Если вы удалите бит выполнения для какой-либо команды или сценария, он все равно может быть передан любой другой программе в качестве аргумента. Если та другая программа знает, как выполнить вашу команду, удаление бита exec на самом деле не имело значения. Например, скрипт Python foobar все равно будет запускаться интерпретатором Python, если вы просто сделали это из командной строки:
вместо того
То же самое с примером системных команд, таких как «cat». Если вы удалите бит exec из «cat», вы все равно можете передать его в новый экземпляр оболочки для выполнения:
будет работать, даже если вы удалили бит exec из cat и
не делает.
источник
catилиechoже не позволяет запускать его с помощьюsh -c 'cat myfile', ни сsystem("cat", "myfile")языками , как Ruby. Причина, по которой Python может запускать неисполняемые.pyфайлы, заключается в том, что он считывает их как строку текста, а затем использует интерпретатор, чтобы заставить этот текст вести себя так, как будто это код.execveсистемный вызов требует разрешения на выполнение. В системах на основе glibc вы можете вызывать динамический компоновщик как программу, чтобы получить примерно тот же эффект, что и в случае с shebang line (/lib64/ld-linux-x86-64.so.2 /bin/cat), и это работает для меня, даже если файл в командной строке не является исполняемым, ноsh -c catне будет этого делать для вас.