peat: Pete and Repeat are sitting on a fence. …

Here’s a simple python tool that jumps into action when a file changes: peat.

peat is built to execute a command of your choosing, and requires only a list of files to watch as input. As you can see above, probably its most basic use is just to send a message to the screen to announce a change.

But it seems capable of executing almost anything as its target, so you could set it to clean up files, compile a code snippet and run it, or … something completely different.

The syntax to get peat running can be a small challenge; by default peat wants a list separated by whitespace. Check the flags if you want to feed it a list separated by newlines or blank spaces.

I should also mention that in Arch, peat wouldn’t run without calling specifically for python2. On the other hand, it seemed to run without any oddball dependencies or bizarre python libraries, so it may be that it will run well on a vanilla system with no added weight.

I feel like I should mention the long list of file event watchers that are available, so it may be that using python as the basis for a file watcher is still too cumbersome.

And given that their list of features is as wide and long as the list itself, the choice becomes a little more academic. peat is worth investigating if you are comfortable with python and if its advanced handling doesn’t intimidate you. But remember there are many others in the running.

logtop: Kind of like a *top … for a logs

I’m not a log nut. I mean, I don’t spend hours poring over logs to try and find the source of my angst (I’m not a terribly angsty person though).

I do know that’s a favorite hobby for some people and professions, and to that end, logtop may be exciting.

logtop is kind of like a *top, if it makes sense to watch a log continually for updates and changes. And as the author suggests, using logtop in this sense

tail -f /var/log/pacman.log | ./logtop

is much the same as doing this

watch 'tail /var/log/pacman.log | sort | uniq -c | sort -gr'

Bt you could say that equating logtop to that line means it’s not adding much to the classic black-and-white Unixy tools you probably already have.

And given that tail already has an -F flag for following log updates, it might not seem like logtop is actually an improvement.

My example doesn’t do much justice to logtop though, since it is prepared to handle much heavier and more dense log updates, as might happen with machines more powerful and active than my puny Pentium 4.

And given that logtop is prepared to calculate and show line rate stats and contort its output to follow specific formats, I’d be doing a great disservice to logtop by dismissing it out of hand.

But I’m not the best judge of these things, since I already confessed that watching logs was something I do rarely at best. Those of you who find solace or salary in staring at logs … you are the target demographic here. 😉

inotifywait, inotifywatch and incron: A package deal

I have two or three related titles I’d like to combine today, but I know I probably won’t do justice to any of them. The first two are inotifywait and inotifywatch from the inotify-tools suite, and the other is incron. All of those rely on inotify‘s filesystem notification to alert you when something in storage has changed.

We’ve seen tools like this before — like wendy or watchfile.sh or fsniper or entr — and for the most part, everybody has their own ways of doing things. inotifywait is something valadil mentioned a few months ago, and his (her?) example was good as a starting point. I’ve modified it a little bit:

kmandla@6m47421: ~$ inotifywait vimwiki/index.wiki && echo "File changed!"

The net result being:

inotifywatch works a little differently, keeping track of changes and events and offering a table of results at the end.

kmandla@6m47421: ~$ inotifywatch -t 30 -r vimwiki/*
Establishing watches...
Finished establishing watches, now collecting statistics.
total  access  attrib  close_write  close_nowrite  open  delete_self  filename
25     5       0       0            10             10    0            vimwiki/index.wiki
15     3       0       0            6              6     0            vimwiki/ffff.wiki
15     3       0       0            6              6     0            vimwiki/yyyy.wiki
10     2       0       0            4              4     0            vimwiki/nnnn.wiki
5      1       0       0            2              2     0            vimwiki/cccc.wiki
5      1       0       0            2              2     0            vimwiki/fd.wiki
5      1       0       0            2              2     0            vimwiki/fselect.wiki
5      1       0       0            2              2     0            vimwiki/jjjj.wiki
5      1       0       0            2              2     0            vimwiki/ncmpcpp.wiki
5      1       0       0            2              2     0            vimwiki/yohackernews.wiki
4      0       1       1            0              0     1            vimwiki/.index.wiki.swp
4      0       0       0            2              2     0            vimwiki/pppp.wiki

The main point should be visible here: That you can collect statistics on folder or file usage just by letting inotifywatch run, rather than hinging an action on a file changing.

incron is the last one of these three, and I do it the most disservice by not having anything to show for it. There are two reasons for that; one is that it would take quite a bit to get it configured and working, and second, I couldn’t show you anything specifically incron was doing.

That’s because incron is a cron-style daemon that relies on file changes to trigger events, rather than time periods … which does make me wonder if the “cron” suffix — which I always took to be a mnemonic for “chron,” as in “chronological” — is really appropriate.

Naming conventions aside, incron would only trigger some other program, and I’d be handing you a screenshot of an unrelated program, and saying, “That’s incron. See? See?” 🙄

Regardless, if you find yourself triggering a lot of specific events on a variety of file changes, you might want to consider setting up an incron array, rather than a battery of inotifywait commands.

I think that’s good for now. Any one of these tools could be an alternative to the three or four home-grown ones we’ve seen in the past. Depending on your needs and resources, of course. 😉

wendy: Under wendy’s watchful eye

I know we just saw watchfile.sh the other day, but I can’t account for the whims of alphabetical order.

tsar11 sent a link three or four months ago to a reddit post about wendy, which monitors files (or directories, for that matter) for changes, and then executes a command as a response.

As you see there, it could be something as simple as a message on screen, or it could be as complex as an order to recompile a program.

wendy can discriminate between file modification, file creation and file deletion, which is handy. If I had told it to spawn a warning only when a file was created, that gif probably would have been shorter. 🙄

wendy also knows enough to keep quiet when told, or to poll at distinct intervals. All nice touches.

I don’t have any complaints about wendy. It seems to handle more complex cases than watchfile.sh, works better than fsniper did (for me), and seems to work at least as well as entr.

wendy’s home page shows edits within the past few months, so if you find there’s a feature it lacks (for one, I’d like to see the option to discriminate actions based on either modification, deletion or creation), the author is probably listening.

In the mean time, your homework will be to daisy-chain all four of these together and see what kind of ruckus erupts as a result. 😈

watchfile.sh: Perhaps the best thus far

It’s been a while since fsniper, and even longer since entr. Here’s watchfile.sh, which also watches files for changes, and then executes a command.

It’s a little difficult to show, so you might have to use your imagination. There are several ways to cue it; in my test runs, this:

./watchfile.sh test.txt cat test.txt

was enough to refresh the screen with my edits, when I saved test.txt back to disk from another terminal window.

That’s not the only way to use watchfile.sh, and the help flags will give you ideas on other methods. For example, you can monitor the output of a second command, and when that changes, execute a third command.

I like watchfile.sh a lot better than either fsniper or entr. fsniper was a bit more complex, and in the end, didn’t quite work. entr, on the other hand, worked fine, but expected to receive updates through a pipe, which is a tiny bit clunky.

But watchfile.sh is very straightforward and very flexible, and does what it promises. And I like that the task is reduced to an easily dissected script, rather than complex code.

So my advice, if you have to pick one of the three, is to go with watchfile.sh. Unless of course, you have another method you prefer. 😉

fsniper: Despite my misgivings

I’m going to include fsniper today, even though I am tempted to drop it into my list of nonworking or possibly out-of-date software.

I’ve known a about fsniper for a long time, but I’ve rarely had the occasion to use it. In principle, it’s quite simple. fsniper watches a directory, and if anything changes in that folder, fsniper executes a command.

We’ve seen this idea in action before, with entr. No doubt there are other applications that do much the same thing.

fsniper has some configuration to set up before it will do its job though. It’s much more finicky than entr, but the tradeoff is that it is much more flexible too.

fsniper can screen events by file type, by mime type or even just by the name of the file. And it can handle multiple options within the same folder, or report errors.

So conceivably you could set up fsniper to watch a folder, and any time a code file changes, it automatically triggers the compiler. If the compiler ends with an error, fsniper knows to trigger a second command — maybe an error report or send a bell to the terminal.

I’m just imagining here. The problem is, and the reason I don’t have a screenshot, that I had some difficulty getting fsniper to do what it promised.

I had configuration files and the program installed and ran fine, but wouldn’t “do” anything when there was a change. More than likely I had it set up wrong. That happens quite often.

And I could see in the log file that fsniper was catching the change, triggering the command, but nothing would appear on my screen. Hmm. 😕

My only other misgiving about fsniper is that the home page was unresponsive for me. The download link still works, but it always makes me twitchy when a home page 403s … or just doesn’t show.

Be that as it may, I’m 99 percent sure fsniper works. But if you mis-configure it like I probably did, you might not get that last 1 percent going. Such is life. 😐

entr: Watching while you work

Here’s a nifty tool that does something I never really gave thought to: entr.

Short for “event notify test runner,” entr watches a file or directory, and if anything in that list changes, it executes a command. And then watches again.

Simple and clever. So while you’re editing an HTML file, at every write, you could trigger your browser to refresh.

Every time you change a line of source code and save it, you could recompile a program. Every time you add a line to a list of names, you could update a sorted version.

The home page has a lot of ideas that go much deeper than my trivial ones. And entr has a few command-line options that will satisfy peculiar cases.

Best of all, updated a little over a month ago. If you have ideas or questions, the developer might like to hear from you on this one. Enjoy.