Детали выполнения сигнала
Цвета ls может представить полномочия, значения по умолчанию для некоторых систем должен показать каталоги, где у всех есть полномочия записи с зеленым фоном:
Можно изменить цвета путем редактирования Вашего $LS_COLORS переменное использование dircolors (от man ls):
Using color to distinguish file types is disabled both by default and
with --color=never. With --color=auto, ls emits color codes only when
standard output is connected to a terminal. The LS_COLORS environment
variable can change the settings. Use the dircolors command to set it.
Синтаксис является по общему признанию довольно раздражающим здесь, но можно изменить этот цвет путем создания файла с цветами, которые Вы хотите и сохранение его как ~/.dircolors:
dircolors -p > ~/.dircolors
Та команда распечатает значения по умолчанию в ~/.dircolors. Необходимо будет затем отредактировать тот файл и изменить эту строку:
OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
Например, для создания этого черным текстом на красном фоне (см. здесь для списка цветовых кодов):
OTHER_WRITABLE 30;41 # dir that is other-writable (o+w) and not sticky
У Вас не должно быть всех значений по умолчанию, можно также просто создать файл с одной строкой, переопределив просто ту, которую Вы хотите изменить. Так или иначе, после того как Вы создали файл, загрузите его:
eval "$(dircolors ~/.dircolors)";
И здесь это в действии:
Чтобы иметь, которые происходят автоматически, добавьте eval команда выше к Вашему ~/.bashrc файл.
1) Обработчик сигнала выполняется в следующий раз, когда целевой процесс возвращается из режима ядра в режим пользователя.
Это происходит либо тогда, когда процесс запланирован на повторный запуск после аппаратного прерывания (и он еще не работал в режиме ядра), либо когда процесс возвращается из системного вызова (на некоторых архитектурах это одно и то же. ).
При нормальной работе, выйдя из режима ядра, ваш процесс просто вернется к следующей инструкции после точки, в которой он первоначально вышел из пользовательского режима.
Однако, если для вашего процесса ожидается сигнал, ядро перезапишет контекст вашего процесса так, чтобы возврат в пользовательский режим вместо этого перешел к первой инструкции вашего обработчика сигнала, и ваш стек будет были изменены, чтобы выглядеть так, как будто вы выполнили "специальный" вызов подпрограммы для обработчика сигнала в точке, где вы изначально вышли из пользовательского режима (возврат из этого "специального" вызова подпрограммы включает выполнение системного вызова для восстановления исходного состояния).
Для получения подробной информации прочтите это , это и this .
Итак «целевой» процесс может получить свой токен выполнения от Планировщика любое количество раз, прежде чем обработчик сигнала будет окончательно выполнен (если он останется в режим ядра почему-то).
2) Нет - обработчик сигнала будет выполняться только в контексте пользовательского режима вашего процесса.
3) На самом деле нет никаких приоритетов выполнения в системе с разделением времени, такой как Linux, если только вы не подсчитываете значение процесса nice , поэтому вы не можете сметите то, чего там нет.
Все усложняется потоками и так называемыми политиками планирования в реальном времени , поэтому приведенные выше комментарии действительны только для однопоточных процессов, выполняемых с политиками планирования не в реальном времени (единственный вид процессов которые существовали в старые добрые времена :-).