On Wed, 2010-04-14 at 12:04 +0300, Timo Sirainen wrote:
I don't think the process creation is much of an issue. But something like this could work:
doveadm expunge -A <
The above syntax would probably have to use IMAP parser.
doveadm fetch subject "(foo)"
This works nowadays though. It's possible to use:
doveadm fetch INBOX \( subject "(foo)" seen \) or unseen
This works because there are now "IMAP parser" and "command line parser". The command line parser knows that after subject there must come a string, so it's not confused by the () characters. Then it also knows that when "(" or ")" comes in a separate parameter, it means a list. Actually it would have been possible to support \(subject without space after \(, but this won't work with the ending \):
\(subject "(foo)"\)
vs.
\(subject "(foo))"
would look identical to doveadm. So I thought it's better to always require the space.
but that makes it more difficult to add variables, because if you do:
doveadm fetch 'subject "$foo"'
$variables also work nicely now without having to escape them.
Now, the next problem is how to select what to fetch and what the output format should look like. I'm thinking about:
doveadm fetch INBOX "flags uid hdr.received hdr.from body" all
would look like:
===sep flags: \seen \draft $Label1 uid: 1234 hdr: Received: stuff Received: more stuff From: tss@iki.fi
body: message body .. ===sep flags: ..next message.. ===sep
The ===sep is a randomly generated separator string that begins always with "===", optionally it could be given as parameter. I was wondering about how to return hdr.* fields, if they should be returned separately or all in one "hdr". Otherwise separate fields would be nice, but if the header exists multiple times, it's not so clear anymore how it should be written. So if there's a single hdr then it's at least easy to understand that it ends with an empty line.
Besides the example parameters above there could be "hdr" = full header and "text" = alias for "hdr body".
It would be nice also to support something like:
doveadm search INBOX from tss@iki.fi
doveadm next|less doveadm next|less ..etc..
So the "next" would return the next matching message based on the previous search. I'm not really sure where the state could be kept though. Would be nice if it was terminal-specific, and would be nice if it didn't write any temporary files.