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.

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. 😉

patch: Piecing together what I should say

I’m a little timid about mentioning patch, mostly because I have a feeling that there are literally thousands of people who know patch a lot better than me.

I’ll spare you the action-packed screenshot this time, since I can’t really patch anything without both target code and a viable patch to use.

My earliest run-ins with patch, aside from blind and wild swings while using Ubuntu, were while tinkering with Crux ports, years ago.

These days I occasionally have to fine-tune an errant PKGBUILD with patch, but that’s the exception and not the rule.

So my experience with patch is very superficial and I won’t embarrass myself by throwing out random suggestions. Especially when I am sure there are many verified experts hovering on the fringe, ready to answer questions.

patch is obliquely related to diff, which we looked over a long time ago. In Arch though, patch lives in its own package (named patch, as you might expect 🙄 ). In Debian? Wouldn’t you know it, patch is in patch.

Which I suppose means you could have one installed on your system, but not the other. Why you would want that is beyond me. 😐

So now that I’ve told you basically nothing about a tool that’s just about everywhere at once, I’ll shut up. If you can’t say something nice — or in this case, smart — don’t say anything at all. 😳

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.