Я написал небольшой «демон» в bash, который переключится на наушники, если они обнаружены, а если нет, переключится на внешний USB-динамик с помощью PulseAudio.
То, что я ищу, - это какой-то способ получать уведомления об изменениях в файле /proc/asound/card0/codec#0
, так же как inotifywait
и в реальных файлах (рассматривая файлы в / proc как «псевдофайлы»).
Я нахожу мой код немного безумные, потому что он работает sleep 1
с в awk
течение всего дня, то есть 86400 раз в день :)
while sleep 1; do
_1=${_2:-}
_2=$(awk '/Pin-ctls/{n++;if(n==4)print}' '/proc/asound/card0/codec#0')
[[ ${_1:-} = $_2 ]] ||
if [[ $_2 =~ OUT ]]; then
use_speakers
else
use_internal
fi
done
Я ищу что-то вроде (этот пример не работает):
codec=/proc/asound/card0/codec#0
while inotifywait $codec; do
if [[ $(awk '/Pin-ctls/{n++;if(n==4)print}' $codec) =~ OUT ]]; then
use_speakers
else
use_internal
fi
done
Таким образом, команды внутри цикла будут выполняться только при наличии реальных изменений в $codec
файле.
top
и системные мониторы с графическим интерфейсом читают намного больше, чем/proc
за короткие промежутки времени. Конечно, они, вероятно, делают это гораздо более эффективно, чем скомпилированные исполняемые файлы, но суть в том, что опрос информации является обычной задачей./proc
, вы, вероятно, можете запустить свой сценарий с помощью правила udev , что было бы довольно идеально. Менее идеальным является то, насколько скучно придумывать правила udev;)Ответы:
Вы не можете, потому что они не файлы. Это не совсем дублирующий вопрос, но ответ здесь объясняет почему.
/proc
интерфейс ядра Там нет реальных файлов, поэтому они не могут измениться. Чтение из дескрипторов - это запрос, а данные в файле, когда вы читаете его, являются ответом на это.Единственный способ, которым вы могли бы смоделировать что-то подобное, это прочитать файл через определенные промежутки времени и сравнить содержимое, чтобы увидеть, изменился ли ответ от ядра - похоже, вы уже сделали это.
Если вы
stat
procfs файлы, atime и mtime будут одинаковыми: для некоторых файлов это всегда, когда был вызов stat, для других - время во время загрузки системы. В первом случае, кажется, что он всегда изменился, во втором - никогда не изменится.источник
fork()
и тому подобное стоит дорого; Как уже упоминалось, утилиты, написанные на языке C, будут иметь более быстрые методы. Я все еще не думаю, что вы увеличиваете нагрузку на систему в целом.Если вы используете PulseAudio, сделайте
pactl subscribe
это.источник
subscribe
в 2.0 не было.Также имейте в виду, что некоторые файлы, для которых
/proc/
разрешено отслеживание изменений с помощью опроса, например, если вы этоman proc
сделаете, можете прочитать о/proc/self/mounts
файле следующее :И это именно то, что реализуется в следующем вопросе:
/programming/5070801/monitoring-mount-point-changes-via-proc-mounts
источник
Попробуйте использовать
netlink
для мониторинга/proc
измененных файлов.https://mdlayher.com/blog/linux-netlink-and-go-part-1-netlink/
источник
netlink
для достижения этой задачи; это не видно из внешнего контента, на который вы ссылаетесь. Кроме того, в общем случае предпочтительнее не иметь ответов «только для ссылок», поскольку внешний контент может измениться или быть удален (см., Например, уведомление в верхней части вашей изначально связанной страницы), что уменьшит полезность вашего вклада.