2011-09-14 8 views
9

私はクロスプラットフォーム(LinuxおよびOS X)ファイルウォッチャーを探しています。そうすることで非常に効率的です)。クロスプラットフォーム(Linux/OS X)ファイルシステムウォッチャー(ファイルが変更されたときに実行コマンド)

これは、継続的インテグレーションサーバのコア部分であること、そして、そのような、LESS/SCSSをコンパイルJavaScriptのテストを実行し、カスタムスクリプトを実行するように物事を処理します。ファイルやディレクトリのリストと、ファイルやフォルダが変更されたときに実行するコマンドを指定したいと思います。

node.js、python、シェルスクリプト、またはルビーベースのものが必要です。

私がこれまで見てきたツールの一部

...

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#連続コンパイル

www.javascriptkata.com/2010/10/28/ready-js-prepare-your-javascプロダクション用/

評価が高く評価されています。

答えて

0

彼らは、正規表現パターンのためにファイルをテールするcollectdプラグインです。しきい値とアラートスクリプトを結びつけることができます。

1

クロスプラットフォームですか?とても難しい。私は効果的なクロスプラットフォーム実装を知らないが、おそらく、私は出発点を示唆することができます。

LinuxはiNotify API、ファイルシステムを監視し、すぐに関連するイベントへの気配りアプリケーションに警告カーネルの機能を備えています。 BSD/Mac-OSに相当するのはkqueueです。 2つのAPIはお互いに非常によく似ています。

私は、CPAN上でそれらのそれぞれのためのいくつかのperlのラッパーを発見しました。私はPythonでの経験はありませんが、phytonでもこれらのAPIのラッパーを検索しました。あなたは ""しか持っていないので、クロスプラットフォームのライブラリを入手するために独自のラッパーを書くことができます。

0

は十分なシェルスクリプトですか? * 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 
+0

これは比較的効率的ですが、これはポーリングです。 –

+0

投票する場合は、cronジョブを実行してください。 – Joost

0

あなたのビルドとテストの手順を自動化したいと思っています。継続的な統合が道です。

gitを使用している場合、gitリポジトリにトリガをインストールする方法はありませんか?トリガー(ローカルリポジトリーで実行中)が変更をプッシュし、ビルドサーバーでビルド/テストサイクルをアクティブにすることができます。 gitを使用していない場合、他のバージョン管理システムにも同様の機能があります。

0

Guardは、自分の特長リストによると、バージョンinotify経由FSEventおよびLinux経由でOS Xのファイル変更の検出をサポートしています。我々は、継続的な統合のために仕事でそれを使用しており、それは非常にうまく機能します。

4

Cで書かれている以外、entrはあなたが望むように見えます。

0

fswatchは、新しいファイルを監視したい場合には特に適しています。

効率性&安定性は基本となるOS APIによって異なります。 fswatchの

制限が使用されているモニターに大きく依存:

  • FSEventsは監視、利用可能な唯一のOS X上で、既知の制限がありませんし、スケールここで、プロジェクトのREADMEからの関連抜粋ですファイルの数が非常によく、 が観察されています。
  • kqueueを特徴とする* BSDシステムで利用可能なkqueueモニターは、監視されているすべてのファイルに対してファイル記述子を開く必要があります。 その結果、このモニタは、ファイル数が で、ひどく縮尺されており、fswatchプロセス がファイル記述子を使い切った直後に動作を開始する可能性があります。この場合、fswatchはオープンできないすべてのファイルに対して 標準エラーで1つのエラーをダンプします。
  • カーネル2.6.13以降のLinuxで利用可能なinotifyモニタは、イベントがキューからの読み込みよりも速く生成されると、キューがオーバーフローする可能性があります。いずれの場合でも、アプリケーションは が正常に処理できるオーバーフロー通知を受け取ることが保証されています 回復します。キューオーバーフロー が発生した場合、fswatchは現在例外をスローします。将来のバージョンでは、適切な 通知を送信することによってオーバーフローを処理します。
関連する問題