Observador del sistema de archivos multiplataforma (Linux/OS X) (ejecuta el comando cuando el archivo cambia)

Question

Estoy buscando un observador del sistema de archivos multiplataforma (Linux y OS X) que no sondee el disco en busca de cambios (o es muy eficiente al hacerlo).

Esta será la pieza central de un servidor de integración continua y manejará cosas como compilar LESS/SCSS, ejecutar pruebas de JavaScript y ejecutar scripts personalizados. Me gustaría especificar una lista de archivos y directorios, y comandos para ejecutar cuando un archivo o carpeta cambia.

Me gustaría algo node.js, python, shell script o basado en ruby.

Algunas de las herramientas que he visto hasta ahora ...

https://github.com/tafa/node-watch-tree

https://github.com/mikeal/watch/blob/master/main.js

doc.qt.nokia.com/latest/qfilesystemwatcher.html

Buildr .apache.org/building.html # continuous-compilation

www.javascriptkata.com/2010/10/28/ready-js-prepare-your-javasc ript-for-production/

Cualquier recomendación apreciada.

Answer 1

Su es un plugin de recopilación que une un archivo para un patrón de expresiones regulares. Puede vincular los umbrales y las secuencias de comandos de alerta para que se activen.

Answer 2

¿Multiplataforma? Es muy duro. No conozco ninguna implementación efectiva entre plataformas, pero, tal vez, puedo sugerir un punto de partida.

Linux tiene iNotify API, una función de kernel que supervisa los sistemas de archivos y alerta de inmediato una aplicación atenta a eventos relevantes. El equivalente BSD/Mac-OS es kqueue. Las dos API parecen muy similares entre sí.

Encontré en CPAN, un poco de envoltorio perl para cada uno de ellos. No tengo experiencia en Python pero busqué en Google un contenedor de estas API también en phyton. Tiene "solo" para escribir su propio contenedor a su alrededor para obtener su biblioteca multiplataforma.

Answer 3

es un script de shell suficiente? debe ser multiplataforma para

for FILE in $LIST ; do #caveat if files may contain spaces, set IFS to be a \n 
touch -r "$FILE" "/tmp/$FILE.timestamp" #use /dev/shm if available vs. /tmp 
done 
#... 
while :; do 
    sleep 1 #you need some sleep value to prevent eating CPU 
    for FILE in $LIST ; do 
    [ "$FILE" -nt "/tmp/$FILE.timestamp" ] && modified_action "$FILE" 
    done 
done 

Answer 4

Gran pregunta * de Nix, y bueno para usted para querer automatizar sus procedimientos de construcción y de prueba. La integración continua es el camino a seguir.

Si está usando git, ¿no hay alguna forma de instalar un disparador en un repositorio de git? Puede hacer que su activador (que se ejecuta en su repositorio local) inserte sus cambios y luego active un ciclo de compilación/prueba en un servidor de compilación. El otro sistema de control de versiones podría tener instalaciones similares si no está usando git.

Answer 5

Guard admite la detección de cambios de archivos en OS X a través de FSEvent y Linux a través de Inotify, según su lista de características. Lo estamos usando en el trabajo para la integración continua, y funciona muy bien.

Answer 6

Aparte de estar escrito en C, entr se parece a lo que desea.

Answer 7

fswatch parece ser el camino a seguir, especialmente si también desea controlar nuevos archivos.

Su eficacia & la estabilidad depende de la API del sistema operativo subyacente. Aquí está el fragmento relevante de README del proyecto:

Las limitaciones de fswatch dependen en gran medida del monitor que se utiliza:

• Los FSEvents monitorear, disponible únicamente en OS X, no tiene limitaciones conocidas, y las escalas muy bien con la cantidad de archivos que se observa .
• El monitor kqueue, disponible en cualquier sistema * BSD con kqueue, requiere que se abra un descriptor de archivo para cada archivo que se esté mirando. Como resultado, este monitor se escala mal con el número de archivos que se observa , y puede comenzar a comportarse mal tan pronto como el proceso fswatch se quede sin descriptores de archivo. En este caso, fswatch vuelca un error en error estándar para cada archivo que no se puede abrir.
• El monitor de inotify, disponible en Linux desde kernel 2.6.13, puede sufrir un desbordamiento de cola si los eventos se generan más rápido de lo que son leídos de la cola. En cualquier caso, la aplicación está garantizada a recibir una notificación de desbordamiento que se puede manejar con gracia recuperar. fswatch actualmente arroja una excepción si ocurre un desbordamiento de la cola . Las versiones futuras manejarán el desbordamiento al emitir notificaciones adecuadas de .