Posts Tagged ‘fsniper’

Extending timetrack

Saturday, May 21st, 2011

There are at least three features I feel is currently lacking in my timetrack suite, and two of them should be more easily added than the third.

Monthly breakdown and tagging

Soonish there should be another add-on, presenting hours but broken down on a per month basis.

This would however necessitate an update of the timetrack storage format (I am leaning towards using SQLite).

Tagging is the other simple feature I feel is missing, and again, it would be a much simpler feat to accomplish if stored using SQLite.

The downside to this, of course, would be the dependency on SQLite. I really don’t like to introduce more dependencies than is necessary.

I am, unfortunately, not smart enough to figure out a better (plaintext) format that would be able to accommodate tags, at least not without making the parsing a bloody mess.

Automatic session detection

In addition to that, my introductory post to timetrack yielded a comment from archie which got me thinking. It really would be nice if the sessions started on their own.

I am thinking that for actual coding sessions, this shouldn’t be all that impossible.

For planning and design work (I am thinking mental modelling and time spent just grasping the concepts) it would be harder (and if I do go down the route with SQLite I suspect I’d need to create another script just for simple addition into the database after the fact.

However, for file-bound operations one could try to see if a similar approach to what fsniper is doing couldn’t be used. The technical details of fsniper is described as:

“fsniper uses inotify to watch for when a file is closed after being written to. This means utilities such as touch will cause the event to trigger.”

Most suggested uses of fsniper has always rotated around doing something to the file that was just modified, but from what I can tell, there shouldn’t be an reason that one couldn’t just execute any old script, doing just about anything, for any purpose, when a file in the correct directory has been modified.

This would all hinge on one small detail though: That there is some event in inotify similar to the one fsniper listens for, but for when a file is opened for writing. (This might however be indistinguishable from a file being opened for just reading, and then it would trigger on just about anything…)

Of course, this would also mean that we need some way of graphically asking the user if a session should be started (the script won’t be executed from a visible shell), and for that I am thinking about Zenity for that.

But the best thing about this is that this solution, with inotify, something fsniper-ish and Zenity would represent optional dependencies (iff/when I manage to get some working code for it)



Tuesday, April 19th, 2011

fsniper is one of those really neat tools I’ve found while just taking a stroll through the repositories, but for which I’ve never quite found a good use.

What fsniper does is that it watches one or more directories, for the addition of files of various mime types or that holds a file name that matches a regular expression, and executes a command or a script, aimed at manipulating that file.

Let’s try a practical use for this (thank you bio-geeks for the idea):

I have a bin directory in my home folder (i.e. ${HOME}/bin), and obviously every script I put in that directory should be executable.

watch {
    $HOME/bin {
        *.sh {
            handler = chmod o+x %%

This short example shows what is needed:

  1. We need to know WHERE fsniper should look
  2. We need to know WHAT fsniper should react on
  3. Finally, we need to know HOW fsniper should react

Every now and then I also do a little bit of python coding, so I might want to make these executable as well.

watch {
    $HOME/bin {
        *.sh {
            handler = chmod o+x %%

        *.py {
            handler = chmod o+x %%

The syntax is rather easy to work with, there are just a couple of special stuff (i.e. %% and the accompanying %f and %d)

%% will expand to mean /the/full/path/to/this/file, with %f expanding to the file name and %d expanding to /the/full/path/to/this/

You get the picture.

And as for the matching rules above, yes, I could have used regular expressions akin to /.*\.(sh|py)/ but then I wouldn’t have been able to show you how to expand on the example.

And just like I added another file name matcher, I could just as easily add another directory to watch.

So right now you are probably wondering, where should this configuration file be put? The answer is: ~/.config/fsniper/config

Then there is the small matter of running fsniper, as follows:
$ fsniper --daemon

If you start it up, and check ~/.config/fsniper again, you will notice a log file aptly named “log”. This contains some really handy output for debugging your configuration when things doesn’t do what you expect them to.

Finally, in the ~/.config/fsniper directory you can also create a subdirectory named “scripts”, and fsniper will make sure to append that directory to the $PATH variable.

Very handy for creating handler-scripts for use only with fsniper.

In closing, I just want to say that fsniper can be a bit more complex than this, acting differently based upon what the exit code of a handler was (i.e. we can engineer our scripts to fail graciously, triggering fsniper to try the next handler defined for that directory).

So if I have piqued your interest I wholeheartedly recommend that you check out the following resources:

Thanks for reading, hope you found it useful :)