I'm almost guaranteed to be wearing headphones while at work. I like music. However, when I leave my desk, I rarely pause mplayer. This leaves my headphones leaking out some barely audible nois that may annoy coworkers.

I always lock my workstation when I'm not at my desk. How do I automate a solution here?

xscreensaver lets you watch the state of the screensaver. Let's use this to pause mplayer when I leave, and unpause it when I return.

xscreensaver-command -watch \
  | while read a; do
    echo "$a" | grep '^LOCK' && pkill -STOP mplayer
    echo "$a" | grep '^UNBLANK' && pkill -CONT mplayer
  done

Running the above, mplayer gets suspended when I lock my workstation, and resumed when I unlock it.

I don't normally follow blogosphere drama, or any drama for that matter. The real world isn't highschool. When someone calls you a 'pooface', you ignore them. However, one particular online drama has gone just plain silly, and I feel impelled to comment.

It's gone too far. People have lost their minds.

This bloggercode of conduct draft by Tim O'Reilly is somewhat funny, silly, and downright useless.

Gerard points out the silly flaw in this code of conduct, albeit in an extremely long, verbose way, that the technology and means already exist to prevent "meanies" on the Internet. It's called the "Delete Button".

I'm reading Code 2.0 by Lessig, and he points out that the reality of "cyberspace" is that code is law. Code. Programming. Not a document detailing rules of how to be nice on the internet. He's right, too.

All of this came about becuase some poor (and surely helpless) blogger came under attack with anonymous death threats and such. Standard net citizens call the sources of these things 'trolls', and ignore them.

Is it really possible that an A-list blogger has never seen a troll before? Really? What? Can it really be that they cannot delete comments on their site?

While I feel sorry for this person becuase she clearly has never been exposed to trolls before, and may not understand how to deal with them, I'm pretty sure the best way to deal with this situation is *not* to create a lame, unenforcable "Blogger code of conduct" when in reality the code of conduct in question is meant to be applied to, well, commenters.

Despite that misnomer, it's still silly. The badges are even sillier (yes, O'Reilly created badges for this). The badges are set to indicate the kind of "meanness" you should expect on the comments.

Is that what we've come too? I thought everyone know the internet was full of stupid people. If you didn't know, well, then, I welcome you to the Internet. People will talk about raping your mother, killing your kittens, and try to get you to click on links taking you to goatse or lemonparty.

Look at any website that allows subscriber content: Slashdot, Digg, any web forum, etc. You'll find morons, wannabe pundits, trolls, etc. Some people shouldn't be allowed online. This includes Kathy Siera, who was the source of all of this lame drama.

Here some of are the rules, and my comments:

• When we believe someone is unfairly attacking another, we take action.

  Read O'Reilly's draft. He suggests that we ask them nicely to "publicly make amends". The technology exists to block and delete comments. What else do you need?

• We do not allow anonymous comments.

  Why is this a part of the code? Showing a badge to indicate "We don't allow anonymous comments" is superfluous. If your blog doesn't allow anonymous comments, then it will be indicated in some fashion when you try to submit (or even before). No social code is necessary. This item goes so far as to require a valid email address. We all know how well *that* works, and there certainly aren't entire projects dedicated to anonymous, fake email addresses.

• We ignore the trolls.

  Wow, I'm glad that was in there. "Ignore the morons" seems like such a hard concept it needs to be documented.

I can't wait to see how this pans out, mostly becuase I enjoy people being stupid. People freaking out and making drama about something so stupid can't possibly go well, especially when many of those people are "important" (I use the term loosely) and have lots of money to throw at the situtation.

wxs has this neat tag cloud thing on his site. I like it so much, I wanted it here on this site, so I installed plugin last night and put it in place of the 'categories' section of the sidebar.

However, the default tag cloud isn't sorted, so finding things in it is, well, hard.

Here is a patch that will sort your tag cloud alphabetically.

For a few days now I've felt that grok should have some kind of mailing list. Why? It's maturing and now is the time to start building a community.

What hosting provider should I use? Sourceforge, berlios, and other open source hosting sites may provide mailing lists, but they also provide things I don't need: CVS repository, web hosting, etc. All I needed was mailing lists.

I had forgotten about Google Groups! I created a new list for grok, grok-users@googlegroups.com. There are lots of administrative options available to me as an admin, and the interface to those options doesn't suck.

Free and easy mailing list hosting? I'll take it.

Please join me the on the grok-users mailing list :)

Group URL: http://groups.google.com/group/grok-users/

In my last post, I discussed a way to perform additional assertions on a given captured group while still inside of the regex state machine.

I spent some time today and implemented it in grok and it works like a charm! This kind of functionality gives you extreme power in the kind of matches you can specify.

Here's an example: How can we find the first number on a line that's greater than 20?

% jot 50 | xargs -n15
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
46 47 48 49 50

Using the above as our sample input:

% jot 50 | xargs -n15 | perl grok -m "%NUMBER>20%" -r "%NUMBER%"
21
31
46

The assertion '>20' is applied during the regular expression match. This is sweet!

Another example would be to 'grep' the output of 'ls -l' for any lines containing a number greater than 5000:

% ls -l | perl grok -m "%INT>5000%"
-rw-r--r--  1 jls  jls   21590 Apr  2 20:17 foo
-rw-r--r--  1 jls  jls   22451 Apr  2 23:52 grok
-rw-r--r--  1 jls  jls  129536 Apr  2 23:47 grok-20070402.tar.gz
-rw-r--r--  1 jls  jls   13539 Mar 22 14:22 grok.1

The equivalent awk statement would look like this:

% ls -l | awk '$5 > 5000'

But if you look at the awk statement, you have to count columns. With grok's solution, all you need to know is you want any line with an integer greater than 5000. You are able to specify the specifics of your match without having to know the precise layout of the data you are matching.

What do you get if you can chain predicates? I haven't added that functionality yet, but it would be trivial to add, so expect it soon.

If you're interested, please try the latest version.

The past two days have been a frustrating exercise in working around a perl bug coupled with putting strong pressure on the limits of perl's regex system. The battle was won, but perl left some scarring..

In the last batch of updates in grok, you are now able to specify additional match predicates to the patterns. For example, if you have: "%IP~/^192/%" it will match an IP, but only IPs starting with 192.

This works great if it's the only IP on the line, but what if you want to grep for an IP starting with 192 on a line with multiple IP addresses? The current implementation works something like this:

1. Perform the match for %IP%
2. Assert that the matched IP also matches the predicate /^192/
3. If the previous assertion succeeded, continue as normal (react)
4. If the assertion failed, drop this line and keep going

Let's consider a simple example:

I want to use %WORD% to match a word. However, I only want a word that has 'foo' in it. Under the current implementation, I might consider using "%WORD~/foo/%" but this would not work, becuase it would match the first word only, which may not match 'foo' as well, and fail. Regex predicates should ideally be involved during the match process, not after. Perl has some crazy code eval features that let you do this. The following code should work:

echo "foo foobar foobaz" \
| perl -nle 'm/(\b\w+\b)(??{ ($^N =~ m@bar@ ? "" : "(?=.\\A)") })/'

Basically, the (??{ }) part checks if the captured group also matches 'bar'. If it doesn't match 'bar' it will inject a regular expression that cannot ever match (guaranteed negative match). The negative match is accomplished with a forward-lookahead looking for any character followed by the beginning of the string (\A), which clearly isn't possible (Neat hack!). The end result is that $1 should be 'foobar'.

However, if you try to run this code:

$ echo "foo foobar foobaz" \
  | perl -nle 'm/(\b\w+\b)(??{ ($^N =~ m@bar@ ? "" : "(?=.\\A)") })/'
> Segmentation fault (core dumped)

Perl crashes. It crashes on linux, freebsd, and solaris in various versions and various permutations of code. It must have to do something with doing other regular expressions inside code evals running from another regex. It seems like it smashes the stack in some unpleasant way.

Frustrating! I spent a few hours trying to fix this without solving the problem. No luck. Shortly after, an outrageous idea hit me - if it is unsafe to do regex within regex, why not fork and do the inner regex in another process?

Sounds crazy, and stupid, and silly? That's because it is. What bug work-arounds aren't? :)

That's exactly what I did. I wrote a short prototype script to test this new subprocess theory. It seems to work! Despite it's outrageous complexity, it gets the job done and skirts around the perl bug.

The script matches an IP, and ensure that that IP contains a '5'. Here's an example run:

scorn(~) % perl regexp-fu.pl "1.2.3.4 8.1.1.4 1.2.3.5"
1.2.3.4 / (?-xism:5)
8.1.1.4 / (?-xism:5)
1.2.3.5 / (?-xism:5)
Match: 1
Group: 1.2.3.5

You can see that it matched 3 IPs, but only the 3rd one had a '5' in it. The result of the 1 regular expression is that it matched the one I wanted. Finally!

I used perlbug(1) in an attempt to report this bug, but I have no idea if it actually sent any email.

This solution is totally suboptimal, but it works. Given the alternative, perl crashing, I'll take this solution.