访问文件时可以运行脚本吗？

可以使用命名管道来实现这一点：

#! /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

像 shell 在>此处所做的那样，在运行之前以只写模式打开 fifogenerator会挂起，直到另一个进程以读取模式打开它。

因此generator程序打开文件后就会立即启动。

我们每次都创建一个新的 fifo（用 原子替换），以避免在程序尚未完成读取第一个输出时启动mv第二个实例并将输出提供给同一个管道。generator

假设程序按顺序读取文件，并且没有其他进程同时尝试读取该文件。

否则，我必须定期重写此配置，但源数据的更改或程序读取之间可能会有几小时或几秒的间隔。

无论如何，你都不应该这么做：覆盖文件，你就冒着在写入时重新加载的风险，因此会在无效的状态下读取！

相反，您应该将所需的配置写入单独的文件（通常在同一目录中），然后使用mv（用 Unix 的话来说，系统调用）以全新rename的配置文件原子地替换整个旧配置文件。

现在，

但源数据的变化之间可能存在几小时或几秒的间隔

那么，仅当源数据发生变化时才进行替换，而不是“总是”进行替换？在我看来，这是显而易见的做法。

只需有一个后台作业（“守护进程”）来监视源数据（无论如何工作！通常，您不必监视，您可以收到有关更改的通知，并且可以让您的程序在此之前处于休眠状态）。并且当且仅当它发生变化时，才会触发写入新的（临时）配置文件并替换现有配置文件。

现在，如果这种情况每隔几秒钟就会发生一次：对于计算机来说，这基本上就是永恒，所以除非你真的对此进行了基准测试，并且发现它非常耗费资源，否则……不用担心它会非常耗费资源吗？人类和计算机的时间尺度是如此不同，以至于人类经常担心的事情实际上占用了计算机如此多的时间，以至于这实际上并不重要。

一般来说，从系统设计的角度来看，读取配置文件的程序是一个数据消费者，它会不定期地检查新数据（即，当它读取配置文件时）。

• 如果您在这个数据源中有一个方面——数据消费者可以通过通知您的数据中介来主动触发更新过程：在更新发生之前什么都不做当然是保持低负载的最佳策略（再次，这在实践中可能是次要的）。
• 如果双方都可以通知，那就更好了：您可以一直处于休眠状态，直到收到通知。如果是消费方通知您，并且自上次通知您以来您没有看到来自源方的通知，那么您只需向其提供缓存的数据。什么都没有改变！

因此，我不知道您的来源和接收器实际上是什么——坦率地说，在问题中添加这一点显然会提高它的可回答性——但如果它是一个输入设备，或者它是通过 dbus 会话总线发布更改的东西，或者它是接收网络数据包的东西，或者即使它只是将文件写入目录的东西，这些都是您可以等待的东西，而不必定期重新创建配置文件。

访问文件时可以运行脚本吗？

是的，但如果您的程序是生成的配置文件的唯一“用户”，那么更高效的方法是让现有“程序”的一部分在其主循环中响应inotify(7)接口。当遇到事件时，它将读取所有必要的文件并执行其他必要的操作以在程序内存中保存的内部数据结构中生成配置，然后每当它“做某事”时，它都会使用内部结构而不是读取任何文件。IN_ACCESS

或者，您也可以将文件作为 inotify(7)IN_ACCESS事件处理程序的一部分写入。在这种情况下，应注意禁用事件处理程序（或使用IN_ONESHOT），或在写入文件期间设置内部标志。