2011-09-14 13 views
9

Sto cercando un watcher di file system multipiattaforma (Linux e OS X) che non esegua il polling del disco per le modifiche (o è molto efficiente nel farlo).Watcher di file system cross platform (Linux/OS X) (comando di marcia quando il file cambia)

Questo sarà il pezzo principale di un server di integrazione continua e gestirà cose come la compilazione di LESS/SCSS, l'esecuzione di test javascript e l'esecuzione di script personalizzati. Mi piacerebbe specificare un elenco di file e directory e comandi da eseguire quando un file o una cartella cambia.

Mi piacerebbe qualcosa node.js, python, script di shell o basato su ruby.

Alcuni degli strumenti che ho guardato finora ...

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/

Qualsiasi raccomandazione apprezzata.

risposta

0

Il loro è un plugin collettivo che codifica un file per un modello regex. È possibile associare le soglie e gli script di avviso per essere attivati.

1

Cross-platform? È molto difficile. Non conosco alcuna effettiva implementazione multipiattaforma ma, forse, posso suggerire un punto di partenza.

Linux ha iNotify API, una funzionalità del kernel che monitora i file system e avvisa immediatamente un'applicazione attenta agli eventi rilevanti. L'equivalente BSD/Mac-OS è kqueue. Le due API sembrano molto simili tra loro.

Ho trovato su CPAN, alcuni wrapper perl per ognuno di essi. Non ho esperienza in Python ma ho cercato su Google alcune wrapper di queste API anche in phyton. Hai "solo" per scrivere il tuo wrapper attorno ad essi per ottenere la tua libreria multipiattaforma.

0

è sufficiente uno script di shell? dovrebbe essere cross-platform per

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 
+0

Questo è un sondaggio, anche se relativamente efficiente. –

+0

Se stai andando al sondaggio, esegui un cron job. – Joost

0

Grande domanda * di nix, e buon per voi per voler automatizzare le procedure di compilazione e di test. L'integrazione continua è la strada da percorrere.

Se si sta utilizzando git, non c'è un modo per installare un trigger in un repository git? È possibile che il trigger (in esecuzione sul repository locale) invii le modifiche e quindi attivi un ciclo di build/test su un server di build. Altro sistema di controllo versione potrebbe avere strutture simili se non si sta usando git.

0

Guard supporta il rilevamento del cambio di file in OS X tramite FSEvent e Linux tramite Inotify, in base all'elenco delle caratteristiche. Lo stiamo utilizzando al lavoro per un'integrazione continua e funziona molto bene.

0

fswatch sembra essere la strada da percorrere, soprattutto se si desidera monitorare anche i nuovi file.

L'efficienza & dipende dall'API del sistema operativo sottostante. Ecco il frammento di rilevante dal README del progetto:

Le limitazioni di fswatch dipendono in gran parte dal monitor utilizzato: monitorare

  • I FSEvents, disponibile solo su OS X, non ha limitazioni note, e le scale molto bene con il numero di file osservato.
  • Il monitor kqueue, disponibile su qualsiasi sistema * BSD con kqueue, richiede l'apertura di un descrittore di file per ogni file guardato. Di conseguenza, questo monitor si adatta in modo errato con il numero di file rilevati a e potrebbe iniziare a comportarsi in modo anomalo non appena il processo fswatch esaurisce i descrittori di file. In questo caso, fswatch scarica un errore nell'errore standard per ogni file che non può essere aperto.
  • Il monitor inotify, disponibile su Linux dal kernel 2.6.13, può subire un overflow della coda se gli eventi vengono generati più velocemente di quanto siano letti dalla coda. In ogni caso, l'applicazione è garantita per ricevere una notifica di overflow che può essere gestito con grazia al recuperare. fswatch al momento lancia un'eccezione se si verifica un overflow della coda . Le versioni future gestiranno l'overflow emettendo le appropriate notifiche .