email2sms is a filter written in Perl which converts an e-mail into a form suitable for sending as an SMS message. Its main advantage over the alternatives is that it uses the CPAN module Lingua::EN::Squeeze to compress the text down to as little as 40% of its original size, so you can get much more of your e-mail into the 160 character limit imposed by SMS. It is fully MIME compatible, and has many configurable options, including removal of quoted text. Ideal for use with procmail. A Perl script for sending the output to a typical e-mail to SMS web gateway is included.
fmscore is a Perl5 program which uses the Mail::Freshmeat Perl module to parse freshmeat daily e-mail newsletters, and then rank them by interest according to highly flexible user-supplied ranking rules. Articles below a specified score will be removed from the output. fmscore is intended/suitable for use as a procmail filter.
GNU Stow is a program for managing the installation of software packages, keeping them separate (/usr/local/stow/emacs vs. /usr/local/stow/perl, for example) while making them appear to be installed in the same place (/usr/local). Stow is a Perl script which should run correctly under Perl 5.005 and above. You must install Perl before running Stow. Stow was inspired by Carnegie Mellon's Depot program, but is substantially simpler.
mptc is a Perl script to help you work out whether you're on the cheapest mobile phone network/tariff for your phoning habits. You feed it an itemised phone bill and tariff pricing information, and it will tell you how much that bill would have cost on different tariffs. So far it only supports UK network pricing systems, but could easily be extended and applied in other countries.
mysqldiff is a Perl script which compares the data structures (i.e. table definitions) of two MySQL databases and returns the differences as a sequence of MySQL commands suitable for piping into mysql which will transform the structure of the first database to be identical to that of the second (c.f. diff and patch). Database structures can be compared whether they are files containing table definitions or existing databases, local or remote.
parp is a powerful, extensible e-mail filter with sophisticated anti-spam capabilities. It's designed as a complete replacement for procmail, is MIME-aware, and acts as a filter, daemon, or on mailboxes. It uses the Open Relay Database as part of its spam-detection heuristics, and it has a DBM-format database of trusted e-mail addresses to ensure that false positives are kept to a minimum. It can perform duplicate removal by message ID, and has many other features.
ttm is a simple but flexible command-line based Perl program for managing lists of tasks. Arbitrary properties can be attached to each task. Standard properties such as `priority', `status' and `categories' are used to provide different ways of viewing the task list. Editing is done with your favourite text editor.
Re: Or you could just use zsh.
> > After all, zsh is better than bash in
> > every single regard.
> > Seriously though, it's unfortunate
> > that we're reinventing all this
> > mechanism for each shell that has
> > programmable completion. The
> > bash-completion folks would like better
> > CVS completion, for example, but the zsh
> > folks have already put lots of work into
> > really excellent CVS completion.
> > Perhaps some sort of shell-independent
> > completion layer, so that we could share
> > this substantial workload? Then maybe
> > application authors could include
> > completion files with their software.
> > Right now they're unlikely to do so,
> > since they'd have to target every shell
> > independently...
It's a nice thought; in fact Felix Rosencrantz has already been doing some experiments on zsh-workers in writing higher-level completion descriptions in XML which gets translated to zsh completion code via XSLT. Have a look at:
> The only problem I have with zsh completion is that it's
> illegible to me (and I say that as a seasoned Perl hacker).
I'm also a seasoned Perl hacker, and while I agree that some bits of the internal code can look like a rat dropping core, there's nothing hugely scary about the API provided for writing your own completions. In fact, it's very pleasant to work with. Look at the _ssh file in Completion/Unix/Command for instance; it's extremely legible. Yes, there's a learning curve there, but it's all very well documented.
> So, while I agree that zsh is a great
> shell (especially in the realm of
> completion), I'd disagree that it's
> better in every single regard.
I'm very curious to hear what advantages you think bash has over zsh (so that I can hack zsh to negate them ;-)