[Spambayes] A kinder, gentler hammie

[Moore, Paul]

From: Neale Pickett [mailto:neale@woozle.org]

> So then, Paul Moore <lists@morpheus.demon.co.uk> is all like:
>
> > On Windows (which I use) "~" isn't handled by the OS. Applications
> > which use it often set the HOME environment variable properly,
> > though, so it *can* make sense. To make this work involves passing
> > filenames through os.path.expanduser().
>
> Hey cool! The audience for hammiefilter suddenly got larger. How
> would you use something like this on a Windows box? Can some MTAs
> run messages through an external filter one at a time? I thought
> only we Unix wonks were able do that ;)

At home, I use an application called Hamster, which is a local
NNTP/POP/IMAP server and a NNTP/POP client, downloading from my ISP
and serving the stuff up locally. Like leafnode on Unix, but for POP
as well as NNTP.

It can run filters on each mail as it comes through, but I don't do
that...

I use Gnus as a client, and for that I use popget.py (which I posted
earlier) to grab mail from Hamster and add the appropriate header.
It's slightly more convenient for me than pop3proxy, but has no
training interface.

I'd use hammiefilter for training - set a command up in Gnus to
pipe the current message out to hammiefilter as spam or ham, as
appropriate.

> I suppose what we could do is try a number of pathnames for the ini
> file, and use the first one that works. If there's some reasonable
> way to figure out what to use for a "home directory" on Windows or
> Mac, without relying on non-standard environment variables, it would
> look there.

Sounds about right. Basically, using relative pathnames in a GUI
environment is error-prone, because you can't be sure what the current
directory is. Windows' normal solution is to use the registry to hold
absolue filenames, but that tends to be messy and generate registry
bloat (as well as being very naive-user-unfriendly).

[Thinking about this, isn't it a problem for Unix as well? What's the
current directory for a procmail filter?]

The standard environment variables which *can* be used for this sort
of thing are

1. HOMEDRIVE and HOMEPATH - %HOMEDRIVE%%HOMEPATH% is basically the
   equivalent of Unix's $HOME. But for nearly all cases, these end
   up being C:\, which to my mind is a bad default.
2. USERPROFILE - %USERPROFILE% is a user-specific directory suitable
   for config information. But by default it's a directory with spaces
   in the name, which can be awkward for some purposes. It's also hard
   to navigate to in Windows explorer, which makes files stored there
   a little "hidden".

Also, many Unix ports (like XEmacs/Gnus) expect the user to set HOME,
so that they can work just like the cosy Unix environment they are
used to. (Python sort of supports this, with os.path.expanduser()).
I personally don't set a default HOME, but set HOME within each
application that expects it (via wrappers or startup scripts or
whatever).

I think "try a number of pathnames" is a sensible approach. I'd
suggest:

    %HOME%\bayescustomize.ini  --  will normally fail, as HOME is not
        set, but helps Unix compatibility for people who care, as well
        as offering an "application-specific" answer for people like me
        who use HOME that way
    %USERPROFILE%\bayescustomize.ini  --  the expected answer for
        people sophisticated enough to want to customise the
        application via an INI file.
    bayescustomize.ini  --  as a final fallback, for commandline use if
        nothing else.

Personally, I think that having an extra stage, where the INI file is
looked relative to the application files, would be good, too. (Ie, look
in the same directory as sys.argv[0]). But opinions on this are often
divided.

> Of course, it could just rely on the BAYESCUSTOMIZE environment
> variable like it does now. But then you'd have to wrap hammiefilter
> to set the variable before running. I'm doing that currently, but I
> think a wrapper around a wrapper around a driver is pretty ugly. ;)

I could use that in my Gnus setup. But what the heck, it would be nice
if it worked in a way that other people coud use as well :-)

> I'll check in some code that works in a Unix environment. Take a
> look at it and let me know what would make sense to try in a Windows
> environment (or just submit a change if you can do that).

Will do. I'll let you know, as I don't have commit privs. (I'll send
you a patch file).

Paul.