É possível executar um script quando um arquivo é acessado?

Um pipe nomeado poderia ser usado para isso:

#! /bin/sh -
fifo=/path/to/stuff.conf
generator() {
  /path/to/stuff.sh "$@"
}
while true; do
  mkfifo -- "$fifo.new" &&
    mv -f -- "$fifo.new" "$fifo" ||
    exit
  generator > "$fifo"
done

Abrir um fifo no modo somente gravação, como o shell faz >aqui, antes de executar, generatortrava até que outro processo o abra no modo leitura.

Então generatorserá iniciado assim que o programa abrir o arquivo.

Criamos um novo fifo toda vez (substituído atomicamente por mv) para evitar que uma segunda generatorinstância seja iniciada e alimente a saída para o mesmo pipe enquanto o programa ainda não terminou de ler a primeira saída.

Isso pressupõe que o programa leia o arquivo sequencialmente e que nenhum outro processo esteja tentando lê-lo ao mesmo tempo.

Caso contrário, eu teria que reescrever essa configuração periodicamente, mas pode haver horas ou segundos entre alterações nos dados de origem ou leituras do programa.

De qualquer forma, você não deve fazer isso: ao sobrescrever o arquivo, você corre o risco de ele ser recarregado enquanto você o grava, e, portanto, ser lido em um estado inválido!

Em vez disso, você iria e escreveria a configuração desejada em um arquivo separado (geralmente no mesmo diretório) e então usaria mv(em palavras do Unix, a renamechamada do sistema) para substituir atomicamente todo o arquivo de configuração antigo por um novo .

Agora,

mas pode haver horas ou segundos entre as alterações nos dados de origem

Então, faça a substituição somente quando os dados de origem mudarem, não "sempre"? Isso me parece ser a coisa óbvia a fazer aqui.

Basta ter um trabalho em segundo plano (um "daemon") que monitora os dados de origem (como quer que isso funcione! Muitas vezes, você não precisa monitorar, pode ser notificado sobre as alterações e pode simplesmente deixar seu programa dormir até lá). E quando, e somente quando, ele muda, isso aciona a gravação de um novo arquivo de configuração (temporário) e a substituição do existente.

Agora, se isso acontece a cada dois segundos: isso é basicamente uma eternidade para um computador, então, a menos que você tenha realmente feito um benchmark e ele acabe sendo muito faminto por recursos, ... não se preocupe com isso sendo muito faminto por recursos? As escalas de tempo de humanos e computadores são tão diferentes que os humanos frequentemente se preocupam com coisas que realmente tomam um tempo tão pequeno de um computador que isso realmente não importa.

Geralmente , do ponto de vista do design do sistema, seu programa que lê o arquivo de configuração é um consumidor de dados que verifica periodicamente se há novos dados (ou seja, quando lê o arquivo de configuração).

• Se você tiver um lado nessa fonte de dados – um consumidor de dados que pode acionar ativamente o processo de uma atualização notificando seu meio de dados: não fazer nada até que a atualização aconteça é, obviamente, a melhor estratégia para manter a carga baixa (novamente, isso pode ser muito secundário na prática).
• Melhor ainda se ambos os lados puderem notificar: você dorme até ser notificado. Se for o lado consumidor que o notifica, e você não tiver visto uma notificação do lado de origem desde a última vez que ele o notificou, então você apenas fornece os dados em cache. Nada mudou!

Então, não sei qual é sua fonte e quais são seus coletores — adicionar isso à pergunta obviamente melhoraria sua capacidade de resposta — mas se for um dispositivo de entrada, ou se for algo que publica alterações por meio de barramentos de sessão dbus, ou se for algo que recebe pacotes de rede, ou mesmo se for apenas algo que grava arquivos em um diretório, essas são coisas que você pode esperar sem ter que recriar periodicamente um arquivo de configuração.

É possível executar um script quando um arquivo é acessado?

Sim, mas se seu programa for o único "usuário" do arquivo de configuração gerado, muito mais eficiente seria ter uma parte do seu "programa" existente respondendo à interface inotify(7) dentro de seu loop principal . Quando um IN_ACCESSevento é encontrado, ele leria todos os arquivos necessários e executaria outras operações necessárias para gerar a configuração nas estruturas de dados internas mantidas na memória do programa, então sempre que ele "fizesse algo", ele usaria as estruturas internas em vez de ler quaisquer arquivos.

Alternativamente, você pode simplesmente escrever o arquivo como parte do IN_ACCESSmanipulador de eventos inotify(7). Nesse caso, deve-se tomar cuidado para desabilitar o manipulador de eventos (ou usar IN_ONESHOT), ou definir um sinalizador interno durante a gravação no arquivo.