Tag Archives: notify

undistract-me: Quashing your ADHD

I fear this little utility might be usable only for a discrete set of fans. Technically speaking it’s a text-based application, but … well, I’ll let you take a look and see what you think.

2015-04-24-lr-0xtbe-undistract-me

In principle, it’s rather simple: undistract-me simply takes note if a shell command takes longer than 10 seconds to execute. If it does, it waits until the program finishes, then throws up the alert message you see in the screenshot above. Kind of cool, in an odd way.

Strictly speaking though, you’ll need all the underpinnings of a graphical desktop, plus whatever alert system is in use there, before you’ll get close to that kind of behavior. On my semi-graphical Arch system with just Openbox, I ended up adding gtk3, polkit, dconf, json-glib and a mess of themes and libraries before the git version was close to running.

So I don’t know if I’m being fair by including it. Don’t expect to suddenly plop this into place on your 400Mhz Celeron running screen, because you’re going to need a lot more to get close.

I won’t deny that I like the idea though, and if something comparable could be implemented in a text only environment, it might be worth trying. For my own part, I used to append long-running commands with aplay yoo-hoo.ogg so I would get an audible when something finished.

So in that way, I can sympathize. But unless you use a lot of terminal commands on a Linux Mint desktop and need some sort of blinky reminder when one finishes … well, like I said, it will probably only appeal to a slim range of fans. :\

Advertisements

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

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

2015-02-25-6m47421-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.

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:

2014-09-11-6m47421-inotifywait

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.

2014-06-22-6m47421-wendy

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.

2013-10-21-lv-r1fz6-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.