[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Request for new command: addresses
From: |
Ralph Corderoy |
Subject: |
Re: [Nmh-workers] Request for new command: addresses |
Date: |
Mon, 02 Jun 2014 14:17:35 +0100 |
Hi,
Paul wrote:
> i'm not convinced that piping "yes n" to a clearly interactive command
> turns it into a "scriptable interface". it's more akin to screen
> scraping. there's no particular reason for "Reply to address?" to
> change any time soon, but also no reason for us to promise that it
> won't. if the feature is important enough to lock down the UI, then
> it's probably enough to do correctly.
I agree. Also, I've noticed a problem with the sed command as given,
s/\<Reply to ([^?]+)\? /\1\n/g
since addresses can contain question marks, e.g.
=?utf-8?Q?Go=20Newsletter?= <address@hidden>
repl(1) gaining a -listaddr might seem easiest.
It seems to me that a suitable mh-format(5) file for repl's -form could
get close to listing just the addresses from the various fields. Or an
mhl(1) file for repl's -filter. I'm hoping a narrow width, e.g. 1,
would cause one address per line. And the addresses could be decoded.
Come to that, ditch repl. If mh-format's language isn't quite up to it
then it suggests it still needs to evolve until it has that embedded
LISP interpreter. :-)
Another solution would be a canonical mail-export format made for easy
parsing, e.g. directory structure with headers in a text file, UTF-8
throughout, no encoding, no line-length limitation, one address per
line, ...
Cheers, Ralph.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Nmh-workers] Request for new command: addresses,
Ralph Corderoy <=