The Party Line tag:blog.tobez.org,2010-01-06://3 2010-01-05T13:24:12Z tobez's personal weblog Movable Type 5.01 New smartmontools and munin tag:blog.tobez.org,2010://3.116 2010-01-05T13:00:26Z 2010-01-05T13:24:12Z With the recent (2009-12-23) update to FreeBSD’s sysutils/smartmontools port smartctl stopped working if run as non-root. I did not investigate whether it is because of the change in the way smartctl operates, or whether it just stopped to be setuid... tobez With the recent (2009-12-23) update to FreeBSD’s sysutils/smartmontools port smartctl stopped working if run as non-root. I did not investigate whether it is because of the change in the way smartctl operates, or whether it just stopped to be setuid root.

Normally I don’t mind going root to run smartctl by hand, but it presents a bit of a problem for the hddtemp_smartctl Munin plugin.

One possible solution is to add the munin user to the operator group, add the following two lines to /etc/devfs.conf:

perm ata 0660
perm xpt0 0660

And finally, run sh /etc/rc.d/devfs restart.

Being the dummy that I am, I only thought about a simpler solution when composing this post: just add user root into the [hddtemp_smartctl] section of your munin/plugin-conf.d/plugins.conf file. Besides being simpler, this method has an added advantage: an updated version of the sysutils/munin-node port can easily incorporate this change. Dag-Erling: hint, hint. :-)

]]> How to time command execution in zsh tag:blog.tobez.org,2009://3.86 2009-03-19T18:55:14Z 2009-03-19T18:57:20Z Often I want to know how long it took for a particular command to finish. An obvious solution to use the time(1) command does not work without a degree of anticipation on my part that I do not normally posess.... tobez Often I want to know how long it took for a particular command to finish.

An obvious solution to use the time(1) command does not work without a degree of anticipation on my part that I do not normally posess.

At some point I became sufficiently annoyed to actually add some hooks to my .zshrc. All commands executed in an iteractive shell are timed, but the reporting is done only for those that took longer than 10 seconds to execute.

This ugly code does the job:

note_remind=0
note_ignore="yes"
note_command="?"

note_report()
{
    echo ""
    echo "note_report: $note_command completed in $1 seconds"
}

preexec()
{
    if [ "x$TTY" != "x" ]; then
        note_remind="$SECONDS"
        note_ignore=""
        note_command="$2"
    fi
}

precmd()
{
    local xx
    if [ "x$TTY" != "x" ]; then
        if [ "x$note_ignore" = "x" ]; then
            note_ignore="yes"
            xx=$(($SECONDS-$note_remind))
            if [ $xx -gt 10 ]; then
                if [ $TTYIDLE -gt 10 ]; then
                    note_report $xx
                fi
            fi
        fi
    fi
}

Enjoy.

]]> Unknown CPAN III: File::SortedSeek tag:blog.tobez.org,2009://3.81 2009-03-13T22:34:05Z 2009-03-13T22:40:26Z Let’s suppose that you have a huge logfile and would like to quickly extract lines from it that relate to a given small time interval. How would you do it? Since the lines are ordered by time specification, the fastest... tobez Let’s suppose that you have a huge logfile and would like to quickly extract lines from it that relate to a given small time interval. How would you do it?

Since the lines are ordered by time specification, the fastest way (provided you do not keep indexes of any sort) is to do the old good binary search, doing all necessary housekeeping to account for line boundaries and converting the timestamp from whatever format it is in the logfile to epoch seconds for comparison with the target interval boundaries.

Since you are dealing with Perl here, it would be natural to first look on CPAN for a module which somebody else has already written to do just this.

And of course somebody has. Enter File::SortedSeek by Dr. James Freeman. The module interface is a bit weird, so it pays off to read the documentation carefully.

At any rate, here is a complete program that handles the task, assuming that the timestamp (in pretty much any format) is at the beginning of each line of the logfile:


#! /usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
use File::SortedSeek;
use Time::ParseDate;

my ($from, $to);
usage() unless GetOptions("from=s" => \$from, "to=s" => \$to);
usage() unless @ARGV == 1;
$from = parsedate($from) if $from;
$to   = parsedate($to)   if $to;

my $filename = shift;

open L, "< $filename" or die "unable to open $filename: $!\n";
File::SortedSeek::set_silent(1);

my $end = File::SortedSeek::numeric(*L, $to, \&time2sec)   if $to;
my $beg = File::SortedSeek::numeric(*L, $from, \&time2sec) if $from;
$end ||= 0;  $beg ||= 0;
while (<L>) {
    print;
    $beg += length($_);
    last if $end && $beg > $end;
}

sub usage
{
    print STDERR <<EOF;
usage:
\t$0 --from date-time [--to date-time] filename
\t$0 -f date-time [-t date-time] filename
EOF
    exit 1;
}

sub time2sec
{
    my $line  = shift;
    return undef unless defined $line;
    my $r = parsedate($line, FUZZY => 1);
    $r;
}

Nifty, eh?

]]> Unknown CPAN II: Time::ParseDate tag:blog.tobez.org,2009://3.77 2009-03-09T16:39:09Z 2009-03-10T11:14:22Z There is a number of very good, but not very well known Perl modules on CPAN. Sometimes I’ll be writing short posts about such modules which I use and appreciate. When you are dealing with date and time in Perl,... tobez There is a number of very good, but not very well known Perl modules on CPAN.

Sometimes I’ll be writing short posts about such modules which I use and appreciate.

When you are dealing with date and time in Perl, inevitably you will reach a point when you need to do more than is immediately available through Perl builtins and the POSIX module.

Then you try to find a module for what you want on CPAN, and you drown in literally hundreds of modules dealing with dates and times.

Luckily, there is a clear winner in this “modules war” - everybody (or at least everybody sane) recommends to use the DateTime module, and for the things that it cannot do, various other modules from the same namespace.

So life is bright for a perl programmer on the date/time front, until you have a need to parse a date represented in one of a multitude of “human-readable” formats, and you don’t know in advance which one it is going to be.

The DateTime itself cleverly refuses to deal with this task at all, and instead recommends to use one of the DateTime::Format:: modules.

You will be relieved to know that you can easily and quickly create parsers for your own date formats - that is, if you are able to remember that you should use the module aptly named DateTime::Format::Builder::Parser::Regex.

The documentation for DateTime::Format::Bork is also very enlightening.

Aaaaanyway.

I prefer to go against the flow here, and use a module somewhat unfortunately named Time::ParseDate. I mean, it could just as easily be Date::ParseTime or something, right? Worse, for years I had trouble remembering what distribution this modules comes from (it, very obviously for everyone but me, can be found in the Time-modules distribution).

At any rate, if we forget for a second about the funny names, this module is truly a wonder:

$ perl -MTime::ParseDate -le 'print parsedate("Sat Feb 14 00:31:30 2009")'
1234567890
$ perl -MTime::ParseDate -le 'print parsedate("2 days ago")'
1236443283
$ perl -MTime::ParseDate -le 'print parsedate("18:30")'
1236619800

It exports a single function, which takes a single parameter (unless you want to specify some options which are rarely needed in practice), and you get your epoch seconds back in return. Very simple, very elegant, gets the job done. I wish there were more “straight to the point” modules like this one.

]]> Unknown CPAN I: Sys::RunAlone tag:blog.tobez.org,2009://3.76 2009-03-07T13:50:59Z 2009-03-07T13:55:52Z There is a number of very good, but not very well known Perl modules on CPAN. Sometimes I’ll be writing short posts about such modules which I use and appreciate. There is a common task of executing a script from... tobez There is a number of very good, but not very well known Perl modules on CPAN.

Sometimes I’ll be writing short posts about such modules which I use and appreciate.

There is a common task of executing a script from cron periodically, subject to the following conditions:

  • a script can occasionally run a relatively long time (longer than the interval at which it is launched by cron);
  • such long runs do not happen often;
  • running two or more instances of the script at the same time will lead to all sorts of strange things happening and must be avoided;
  • skipping a single run is no big deal.

A usual method to prevent strange things from happening is to use a lockfile, like in this example:

use strict;
use warnings;

use Fcntl qw(:DEFAULT :flock);

sysopen(L, "/var/run/myprocess.lock", O_WRONLY | O_CREAT)
    or die "cannot open lockfile: $!";
flock(L, LOCK_EX | LOCK_NB)
    or die "cannot obtain lock: $!";

# ... do work here ...

unlink "/var/run/myprocess.lock"; # optional
close(L);

(You might want to silently exit when flock fails in order to not spam yourself with useless cron mails).

Nothing fancy, really. But over time it becomes boring to write all this housekeeping code in every little cronjob, especially since in some cases the “do work here” part can be comparable in size to the locking part.

The solution, of course, is to use the CPAN magic and to find a module which sweeps all this complexity under the rug, leaving us with a clean and simple interface, so that we can concentrate on getting the job done.

As usual with CPAN, there is not one, but several modules which were written to perform this task. Most of them are rather powerful, which is unfortunate, since we want simplicity of use above all else. The bells and whistles provided by those modules might be needed in certain situations, but for the purpose described above they just get in the way.

There is, however, a wonderfully simple (and a rather clever) module by Elizabeth Mattijsen, Sys::RunAlone. To get the same functionality as the code above, all you need to do is this:

use strict;
use warnings;
use Sys::RunAlone;

# ... do work here ...

__END__

That’s it. Nothing else to write.

There are only two minor things to remember about this module, if you want to avoid problems.

First, it uses the script’s DATA handle to do the locking (that is, it actually uses the script’s file itself). So if you have several symlinks pointing to the same script, you cannot run them at the same time for it is still one physical file and one DATA handle.

Second, and for the same reason, if you modify the script while it is running and then launch it again, it will fail to detect that another instance is already running, since the DATA handle will be different.

Just keep this in mind when you use it.

]]> rrdtool legend box rant tag:blog.tobez.org,2009://3.74 2009-03-05T13:21:41Z 2009-03-05T16:21:33Z Last time I ranted about one thing that is wrong with rrdtool. It turns out that I, unfortunately, have more gripes to share. Let’s talk today about the legend control. The rrdtool’s language for controlling how the graph is going... tobez Last time I ranted about one thing that is wrong with rrdtool.

It turns out that I, unfortunately, have more gripes to share. Let’s talk today about the legend control.

The rrdtool’s language for controlling how the graph is going to look and feel is pretty rich and complex. Among other things, it has a bunch of graphing commands that are able to manipulate the legend section of the graph. Some of those commands do nothing else, while the other commands only modify the legend as a side effect, and primarily exist for doing something else.

Let’s take as an example the graph below:

rrdtool graph x.png
  --end 1235800000 --start end-150000
  'DEF:data=some.rrd:data:AVERAGE'
  'CDEF:sine=data,POP,1235800000,TIME,-,10000,/,SIN'
  'LINE1:sine#0000ff:a sine of foo\l'
  'CDEF:cosine=data,POP,1235800000,TIME,-,5000,/,COS'
  'LINE1:cosine#00ff00:a cosine of bar'

The trouble is that there is no instruction which can produce a so called “legend box” (a small blue box next to the “a sine of foo” legend text) without doing something else in the process. All of the commands that actually graph something can optionally produce a legend box, but there is no other way to make it.

If we extend our sine example with some nice downtime background (in Soviet Russia sines can have a downtime!), we get a nice picture like this:

rrdtool graph x.png
  --end 1235800000 --start end-150000
  'DEF:data=some.rrd:data:AVERAGE'
  'CDEF:downtime=data,0,0,IF,
    TIME,1235769489,GE,TIME,1235779489,LE,*,
    TIME,1235689489,GE,TIME,1235729489,LE,*,+,+'
  'CDEF:sine=data,POP,1235800000,TIME,-,10000,/,SIN'
  'LINE1:sine#0000ff:a sine of foo\l'
  'CDEF:cosine=data,POP,1235800000,TIME,-,5000,/,COS'
  'LINE1:cosine#00ff00:a cosine of bar\l'
  'TICK:downtime#ffe0e0:1.0:downtime'

But let’s suppose that we’d also like to add background coloring for uptime, and indicate that in a legend. Let’s use another CDEF for uptime, which will be just the opposite of our downtime CDEF:

rrdtool graph x.png
  --end 1235800000 --start end-150000
  'DEF:data=some.rrd:data:AVERAGE'
  'CDEF:downtime=data,0,0,IF,
    TIME,1235769489,GE,TIME,1235779489,LE,*,
    TIME,1235689489,GE,TIME,1235729489,LE,*,+,+'
  'CDEF:uptime=downtime,0,1,IF'
  'CDEF:sine=data,POP,1235800000,TIME,-,10000,/,SIN'
  'LINE1:sine#0000ff:a sine of foo\l'
  'CDEF:cosine=data,POP,1235800000,TIME,-,5000,/,COS'
  'LINE1:cosine#00ff00:a cosine of bar\l'
  'TICK:uptime#e0ffe0:1.0:uptime'
  'TEXTALIGN:left'
  'TICK:downtime#ffe0e0:1.0:downtime'

Oops. Of course. The graphing commands are processed in sequence, so the uptime “background” has obscured our actual sinusoidal data! We will have to put the uptime TICK before anything else to avoid this:

rrdtool graph x.png
  --end 1235800000 --start end-150000
  'DEF:data=some.rrd:data:AVERAGE'
  'CDEF:downtime=data,0,0,IF,
    TIME,1235769489,GE,TIME,1235779489,LE,*,
    TIME,1235689489,GE,TIME,1235729489,LE,*,+,+'
  'CDEF:uptime=downtime,0,1,IF'
  'CDEF:sine=data,POP,1235800000,TIME,-,10000,/,SIN'
  'TICK:uptime#e0ffe0:1.0:uptime'
  'LINE1:sine#0000ff:a sine of foo\l'
  'CDEF:cosine=data,POP,1235800000,TIME,-,5000,/,COS'
  'LINE1:cosine#00ff00:a cosine of bar\l'
  'TICK:downtime#ffe0e0:1.0:downtime'

See the problem? Now the legend boxes are not in the right order.

Naturally, it is pretty trivial to solve - we just remove the legend (it is optional) from the uptime TICK, and add another graphing command in the end with the right legend text. We’ll simply have to make sure that this “graphing command” does not actually graph anything:

rrdtool graph x.png
  --end 1235800000 --start end-150000
  'DEF:data=some.rrd:data:AVERAGE'
  'CDEF:downtime=data,0,0,IF,
    TIME,1235769489,GE,TIME,1235779489,LE,*,
    TIME,1235689489,GE,TIME,1235729489,LE,*,+,+'
  'CDEF:uptime=downtime,0,1,IF'
  'CDEF:sine=data,POP,1235800000,TIME,-,10000,/,SIN'
  'TICK:uptime#e0ffe0:1.0'
  'LINE1:sine#0000ff:a sine of foo\l'
  'CDEF:cosine=data,POP,1235800000,TIME,-,5000,/,COS'
  'LINE1:cosine#00ff00:a cosine of bar\l'
  'TICK:uptime#e0ffe0:0.0:uptime'
  'TEXTALIGN:left'
  'TICK:downtime#ffe0e0:1.0:downtime'

Just like the last time - the problem is easily solvable, but it annoys me, since rrdtool again forces us to work against it instead of working with us. It would be nicer to have a way to put a legend box where we want it in some more direct way (maybe a variant of the COMMENT command)?

]]> rrdtool CDEF restrictions rant tag:blog.tobez.org,2009://3.73 2009-03-03T19:40:06Z 2009-03-05T13:31:51Z Last time I spread some rrdtool love around. Love with no hate won’t do, however. Taking a page from the way the BBC and many other news outlets cover certain conflicts, it seems prudent to present an unbiased view of... tobez Last time I spread some rrdtool love around. Love with no hate won’t do, however. Taking a page from the way the BBC and many other news outlets cover certain conflicts, it seems prudent to present an unbiased view of rrdtool. And what better way to do that if not by spreading some hate this time?

Some time ago I had a task of adding background coloring to the portions of a graph, representing downtime of a device. This information was not available in the RRD archive itself, but could be obtained from elsewhere.

The information was in the form of epoch ranges, like this:

1235639489-1235646689,1235725889-1235729489

After some thought, I decided that making a CDEF with some simple RPN magic, in combination with a TICK graphing command would do the trick. The TICK command draws a vertical line of a specified height when a data point is not a zero or an UNKNOWN value, so I naïvely thought that this simple CDEF will achieve what I want (one long line here is split into several lines for your browsing convenience):

CDEF:downtime=0,TIME,1235639489,GE,
    TIME,1235646689,LE,*,
    TIME,1235725889,GE,
    TIME,1235729489,LE,*,+,+

The boolean values in rddtool’s RPN are represented using the usual C-like convention (0 = false, 1 = true), so for any given time point the result of the CDEF above will be 0 if the point is outside any of the downtime intervals, 1 if it is inside one of the intervals, and more than 1 if it is inside several intervals (which should not happen, but is possible if we specify overlapping downtime epoch ranges).

If you did not understand how this is supposed to work, go read the rrdgraph_rpn manpage.

Anyway, that was easy enough, even if it was not very clean. So where is the promised hate, you’ll ask? Here it is:

rrdtool graph x.png --end 1235800000 --start end-150000
    'DEF:data=some.rrd:someds:AVERAGE'
    'CDEF:downtime=0,TIME,1235639489,GE,TIME,1235646689,LE,*,
     TIME,1235725889,GE,TIME,1235729489,LE,*,+,+'
    'TICK:downtime#ffe0e0:1.0'

ERROR: rpn expressions without DEF or CDEF variables are not supported

You’ve read that right! Rrdtool insists that everything you put into a graph must ultimately come from some data source in some RRD archive. How stupid is that?

And the answer is - very stupid indeed, for at least two reasons.

First, it tries to pretend it knows what I might want to do better than me, and I really hate that in software. Whatever has happened to the idea that a tool must not get in the way of its user?

Secondly, this check is easily circumvented by adding a real DEF somewhere in the CDEF and then (mis)using RPN language to get rid of any value which comes from the DEF. There are many ways to do it, some more creative than others, but even this ham-fisted “solution” will do the job:

CDEF:downtime=data,0,0,IF,TIME,1235639489,GE,
    TIME,1235646689,LE,*,
    TIME,1235725889,GE,
    TIME,1235729489,LE,*,+,+

So we have a pointless restriction, and we are forced to work around it. Some might say that working against the tool to reach the goal is somehow challenging and maybe even fun. If you ask me, this is akin to programming in Brainfuck - a kind of activity better performed as a hobby, if that’s your idea of how to spend your copious free time.

To rephrase the Perl’s motto, rrdtool makes simple things hard.

]]> Some rrdtool love tag:blog.tobez.org,2009://3.71 2009-03-01T14:16:50Z 2009-03-05T13:31:11Z Everybody uses rrdtool. Everybody loves rrdtool. I love rrdtool as well. Sometimes it even pleasantly surprizes me. For example, it used to be the case that massive updates of a large number of RRD archives were a bit on the... tobez Everybody uses rrdtool. Everybody loves rrdtool.

I love rrdtool as well. Sometimes it even pleasantly surprizes me.

For example, it used to be the case that massive updates of a large number of RRD archives were a bit on the slow side (this operation is IO-bound, you see).

Quite unexpectedly I found that this inconvenience can be easily circumvented by throwing more RAM into the problem. By itself, this statement is not at all suprizing - after all, we all know about effects of disk caching. It is the magnitude of the improvement that simply astonished me: on a moderately busy box with primary purpose entirely different from doing RRD updates, I am now routinely getting around 18500 RRD acrhives updated in under 1 second. The large majority of the archives has 40+ data sources each, and the rest has 140+ data sources each. The machine has measly 8G of RAM.

Sometimes, when the box is busy doing something with its disks, it might take 3 minutes to finish the updates. In very rare instances it can take up to 15 minutes. But in more than 80% of cases it takes under 1 second.

The setup is such that the actual data collection is completely separated from the RRD update step. In fact, the collection step actually occurs on a different machine, for reasons I am not going to delve into in this post. The collector generates an “RRD update order” file, which is transferred to the target machine, where it is parsed by a simple Perl script, which subsequently executes the corresponding RRDs::update statements, with a small degree of parallelism in this last operation.

The application has been running for some months now, and every time I recall the numbers involved, I cannot help but say “wow!”.

]]> Version-independent location of a CPAN distribution's Changes file tag:blog.tobez.org,2007://3.65 2007-12-20T11:43:39Z 2009-03-01T12:07:36Z Some time ago several people (most notably skv@) ranted about including a list of changes or a link to such list in the commit message for a port update. I thought it was a great idea and started including a... tobez Some time ago several people (most notably skv@) ranted about including a list of changes or a link to such list in the commit message for a port update.

I thought it was a great idea and started including a link to a CPAN’s distribution Changes file in my commits some time ago.

What I did not like was that those links looked like this:

http://search.cpan.org/src/JESSE/Template-Declare-0.27/Changes

FreeBSD’s commit messages are preserved in our repository and mail archives forever, for a suitable definition of “forever”. On the other hand, CPAN authors are encouraged to clean up old and obsolete versions promptly.

Thus there is a discrepancy between expected time of life of the link in the commit message and the link contents.

While older CPAN distributions can still be found on BackPAN, it only provides links to tarballs and not individual files like Changes.

Luckily, it turns out that version-less links like

http://search.cpan.org/dist/Template-Declare/Changes

work just fine, redirecting to the most recent version of the file. This is acceptable, since Changes is expected to be a prepend-only file, so the information the commit message was trying to link to can (almost) always be found there.

]]> Backing up Google Reader subscriptions as OPML, periodically and automatically tag:blog.tobez.org,2007://3.64 2007-10-31T21:07:42Z 2009-03-01T12:07:36Z A fellow former Bloglines user has asked me whether I found a way to backup Google Reader subscriptions into an OPML file from cron, as we used to do with our Bloglines accounts. A quick search turned up this, which,... tobez A fellow former Bloglines user has asked me whether I found a way to backup Google Reader subscriptions into an OPML file from cron, as we used to do with our Bloglines accounts.

A quick search turned up this, which, from the look of it, in order for it to work requires every feed to be explicitly marked with a tag which is set up as public.

This by itself is rather cumbersome, and you have to remember to do that for every new feed you subscribe to, otherwise you’ll defeat the purpose of making periodic backups in the first place.

Luckily, there is a better solution. There is a nice little module on CPAN, WebService::Google::Reader by gray, which uses an unofficial Google Reader API to do various nifty things with your Google Reader subscription, including OPML export.

This means that after installing the module you can simply put the following command into your crontab (only command itself is shown, see crontab(5) manual page to find out what else you will want to put in there):

env GOOGLE_USERNAME=your-username-typically@gmail.com \
  GOOGLE_PASSWORD=your-user-password \
  perl -MWebService::Google::Reader -e \
  'print WebService::Google::Reader->new(
     username => $ENV{GOOGLE_USERNAME},
     password => $ENV{GOOGLE_PASSWORD})->opml' \
  > /where/to/put/greader.opml

You will have to make the above to be one long line to satisfy crontab syntax, and of course remember to use a real username, password, and the path to the resulting OPML file.

Unfortunately, the most recent version of the module (which is 0.03 at the time of this writing) has a minor bug which prevents the opml() method from working correctly. So you will need to do a little patching.

Before installing the module, edit the source file lib/WebService/Google/Reader/Constants.pm, look for a string subscribtions, and fix the spelling (finding correct spelling is left as an exercise for the reader). Then proceed installing the module as usual.

Hopefully, this step won’t be necessary in a couple of days’ time when a new version of the module is released.

If you are a FreeBSD user like myself, you may choose instead to fetch a skeleton of the port of the module. Unpack it in /usr/ports/www/ and install it as you would any other port.

I intend to add the port to the ports collection as soon as our current ports freeze is over.

Enjoy!

]]> Switching between X11 screens and workplaces with keyboard tag:blog.tobez.org,2007://3.56 2007-04-05T13:23:22Z 2009-03-01T12:07:29Z Some time ago I’ve got two monitors connected to my workstation at work. I do not like using Xinerama, so I have, in X11 terminology, two screens, :0.0 and :0.1. It bugged me that I had to move the... tobez

Some time ago I’ve got two monitors connected to my workstation at work. I do not like using Xinerama, so I have, in X11 terminology, two screens, :0.0 and :0.1.

It bugged me that I had to move the mouse cursor to switch between the screens. There must be a way to do it with keyboard, I thought. Some googling revealed a wiki page about dual monitors setup, which had a reference to a little C program, dualmouse.c by David Antliff.

It worked fine if all I wanted to do was to switch from my current screen to “the other one”. But I also wanted to be able to do things like “switch to workplace 4 on screen 0”, and the program could not be used for that.

Fortunately, the wmctrl utility could do things like “switch to workplace 4 on the current screen”, so all I had to do is to modify the dualmouse.c program to support “switch to screen N” functionality, and the rest is, as they say, shell (or Perl) scripting.

The ~/.fluxbox/keys file (if you are using something else than fluxbox, you are on your own here) would have things like:

Control F1 :Exec flux2workspace 0 1
Control F2 :Exec flux2workspace 0 2
Control F3 :Exec flux2workspace 0 3
Control F4 :Exec flux2workspace 0 4

Control Shift F1 :Exec flux2workspace 1 1
Control Shift F2 :Exec flux2workspace 1 2
Control Shift F3 :Exec flux2workspace 1 3
Control Shift F4 :Exec flux2workspace 1 4

And the flux2workspace script looks like this:

#! /usr/bin/perl -w
exit unless @ARGV == 2;
system("dualmouse $ARGV[0]");
$ARGV[1]--;
$ENV{DISPLAY} = ":0.$ARGV[0]";
system("wmctrl -s $ARGV[1]");

Next time: accomplishing the same feat with x2x-controlled displays.

]]> cd to a directory of a file tag:blog.tobez.org,2007://3.55 2007-04-04T19:31:13Z 2009-03-01T12:07:28Z In zsh, define the following function: cd-() { local dir cd `dirname $1` } Then this: cd- /usr/ports/www/linux-opera/Makefile changes directory to /usr/ports/www/linux-opera/. Trivial pleasure, but pleasure nevertheless.... tobez

In zsh, define the following function:

cd-()
{
    local dir
    cd `dirname $1`
}

Then this:

cd- /usr/ports/www/linux-opera/Makefile

changes directory to /usr/ports/www/linux-opera/.

Trivial pleasure, but pleasure nevertheless.

]]> Irssi events notifier with Erlang tag:blog.tobez.org,2006://3.50 2006-07-25T18:04:28Z 2009-03-01T12:07:13Z Once upon a time I was a reasonably happy user of XChat. It had a feature: you could configure it to automatically popup a new window “in your face” for private messages. This was nice, since you would never... tobez irssi dockapp

Once upon a time I was a reasonably happy user of XChat. It had a feature: you could configure it to automatically popup a new window “in your face” for private messages. This was nice, since you would never miss a message directed to you. The feature also had drawbacks:

  • once a window was there, no popping up occured;
  • popping up in your face was annoyingly intrusive;
  • it was common to be typing something else and pressing ENTER without noticing; the :wq!’s in chat windows were numerous; parts of passwords for folks to see were not unheard of.

After some time, and following an advice from friends, I switched over to the IRC client, irssi, and never looked back.

I, as many others, run irssi in text mode (although it supposedly has a GUI, I was never tempted to try it). Moreover, I run it 24/7 under screen control on a reasonably stable and well-connected machine.

Which presents me with the problem that XChat popup windows were trying to solve: I miss stuff. There are various notifiers available for some instant messaging applications. I would not be surprized if some of those are easy to integrate with irssi. But with remote irssi? On one or more of my several desktops? I never heard of such a beast, and so I decided to write one.

The question of presentation solved itself easily: I use fluxbox window manager, which, among other things, provides support for AfterStep and WindowMaker dockapps.

Getting information about events from irssi itself turned out to be a piece of cake, thanks to the tight integration of irssi and Perl.

The question of delivering notifications from the machine irssi is being run on to one or several desktops was somewhat trickier. Initially, I thought that a very-very simple web storage system I wrote will be the ticket. It worked reasonably well, but I did not want to perform the polling more often than every 30 seconds, and I was not satisfied with the delay. The help came from an unexpected side.

Some time ago I started to read up on Erlang, and was impressed with its capabilities for concurrent and distributed processing. So I sought to re-implement ISWEST-based irssi notifier in Erlang as a sort of a novice programming project.

The end result is a piece of software called, not surprizingly, irssi-notifier, which can be downloaded here. It consists of three components.

activity-notifier

This is a Perl script which should be loaded in irssi. Copy it into ~/.irssi/scripts directory, and load it into irssi using the following command:

/script load activity-notifier.pl

You will need the nc program (netcat) installed, since I could not be bothered with more socket programming in Perl.

notifier-server

This is a small (less than a hundred lines of code) Erlang program that serves as a middle point between irssi (with activity-notifier) and your desktop. Normally, it should run on the same machine as irssi itself.

This is a server program, so it is supposed to run indefinitely.

Since I do not know (yet) how to create proper Erlang applications, it should be started like this:

$ cd irssi-notifier/notifier-server
$ erl
> c(notifier).
> notifier:start().

Then leave that Erlang instance running (background it, or something).

I intend to make this somewhat more convenient to use once I learn how to package a proper Erlang application which runs as a daemon together with Erlang runtime.

irssi-dockapp

This is a C program which actually implements the dockapp.

Compile it (a very simple Makefile is included). You will need libDockApp library installed first. Then run it like this:

./irssi-dockapp -t host.where.notifier-server.runs -p 5679

When irssi receives a private message for you or a message that it hilights (such as messages with your nick mentioned) an irregularly shaped red blob will appear in your dockapp almost instantaneously.

There is no limit on the number of simultaneous dockapp connections to the notifier server.

Enjoy!

]]> Extended del.icio.us bookmarklet tag:blog.tobez.org,2005://3.47 2005-11-10T09:41:16Z 2009-03-01T12:07:12Z Dan Phiffer came up with a really neat Google/del.icio.us greasemonkey userscript idea: Use case: I search for “tuna sandwich” and Google brings up http://www.starkist.com/recipes/sandwiches/classictuna.html among a host of other tuna-related links. A Greasemonkey script pays attention to which link... tobez

Dan Phiffer came up with a really neat Google/del.icio.us greasemonkey userscript idea:

Use case: I search for “tuna sandwich” and Google brings up http://www.starkist.com/recipes/sandwiches/classictuna.html among a host of other tuna-related links. A Greasemonkey script pays attention to which link I click on and upon the click event, bookmarks this page with the tags “tuna” and “sandwich”.

People agreed that it is neat, but then Lenny Domnitser replied that the same could be easily and more conveniently accomplished with a simple modification of the “Post to del.icio.us” bookmarklet:

javascript:
var t,q=document.referrer.match(/q=([^&]+)/);
if(q){t='&tags='+q[1];}else{t=''}
location.href='http://del.icio.us/YOURDELICIOUS?url='+
encodeURIComponent(location.href)+'&title='+
encodeURIComponent(document.title)+t;

Simply replace YOURDELICIOUS with your del.icio.us account name, and make it one long line, then add it to your Firefox bookmarks.

Works like a charm, thanks, Lenny!

]]> Selecting words in xterm tag:blog.tobez.org,2005://3.42 2005-09-13T07:50:46Z 2009-03-01T12:07:11Z I’ve been using this feature for years now, and it is surprizing that not many xterm users are aware of it. When one double-clicks in xterm, a “word” is selected. By default, one gets selection like this: http://blog.tobez.org/, if... tobez xterm

I’ve been using this feature for years now, and it is surprizing that not many xterm users are aware of it. When one double-clicks in xterm, a “word” is selected. By default, one gets selection like this: http://blog.tobez.org/, if one double-clicks on an e there. This is OK for some usage patterns, but suboptimal for many others. Fortunately, it is possible to override xterm’s notion of what to select, by using a charClass resource. I have the following in my .Xdefaults file: XTerm*charClass: 33:48,36-38:48,43-47:48,58:48,61:48,63-64:48,126:48 Admittedly, this is a bit cryptic. That’s probably why this feature is so underused. So please, go and read the “CHARACTER CLASSES” section in the xterm manual page, and tinker until satisfied. Oh and by the way, this is a sole single thing which made me switch from rxvt and its various clones back to xterm.

]]>