Observateur du système de fichiers multiplate-forme (Linux / OS X) (commande d’exécution lorsque le fichier est modifié)

Autre que d’être écrit en C, entr ressemble à ce que vous voulez.

Multiplateforme? C’est très difficile. Je ne connais aucune implémentation multi-plateforme efficace, mais je peux peut-être suggérer un sharepoint départ.

Linux possède une API iNotify , une fonctionnalité du kernel qui surveille les systèmes de fichiers et alerte immédiatement une application attentive des événements pertinents. L’équivalent BSD / Mac-OS est kqueue . Les deux API semblent très similaires.

J’ai trouvé sur CPAN , un wrapper perl pour chacun d’eux. Je n’ai aucune expérience en python mais j’ai googlé sur certaines enveloppes de ces API également dans phyton. Vous n’avez ” qu’à ” écrire votre propre enveloppe pour obtenir votre bibliothèque multi-plateforme.

Leur est un plugin collectd qui dépose un fichier pour un modèle de regex. Vous pouvez associer des seuils et des scripts d’alerte à déclencher.

un script shell est-il suffisant? devrait être la plate-forme croisée pour * nix

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 

Bonne question et bonne pour vouloir automatiser vos procédures de construction et de test. L’continuous integration est la voie à suivre.

Si vous utilisez git, n’y a-t-il pas moyen d’installer un déclencheur dans un repository git? Vous pouvez avoir votre déclencheur (exécuté sur votre référentiel local) pour envoyer vos modifications, puis activer un cycle de génération / test sur un serveur de génération. Un autre système de contrôle de version peut avoir des fonctionnalités similaires si vous n’utilisez pas git.

Guard prend en charge la détection des modifications de fichiers sous OS X via FSEvent et Linux via Inotify, conformément à leur liste de fonctionnalités. Nous l’utilisons au travail pour une continuous integration et cela fonctionne très bien.

fswatch semble être la voie à suivre, surtout si vous souhaitez également surveiller les nouveaux fichiers.

Son efficacité et sa stabilité dépendent de l’API OS sous-jacente. Voici l’extrait pertinent du README du projet:

Les limitations de fswatch dépendent largement du moniteur utilisé:

• Le moniteur FSEvents, disponible uniquement sous OS X, n’a pas de limitations connues et évolue très bien avec le nombre de fichiers observés.
• Le moniteur kqueue, disponible sur tous les systèmes * BSD avec kqueue, nécessite l’ouverture d’un descripteur de fichier pour chaque fichier surveillé. En conséquence, ce moniteur évolue mal avec le nombre de fichiers observés et peut commencer à mal se comporter dès que le processus fswatch est à court de descripteurs de fichiers. Dans ce cas, fswatch sauvegarde une erreur sur l’erreur standard pour chaque fichier qui ne peut pas être ouvert.
• Le moniteur inotify, disponible sur Linux depuis le kernel 2.6.13, risque de subir un dépassement de file si les événements sont générés plus rapidement qu’ils ne sont lus dans la file d’attente. Dans tous les cas, il est garanti que l’application reçoit une notification de dépassement de capacité qui peut être traitée pour récupérer avec grâce. fswatch lève actuellement une exception si un dépassement de queue se produit. Les futures versions géreront le débordement en émettant des notifications appropriées.