On Tue, 20 Apr 2010 18:49:10 +0300 Timo Sirainen wrote:
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.
Maybe you should take exim's queue style for such operations. Here few examples:
#exim -bp //return queue in format:
4d 99K 1O36Eu-0001Py-Ts mykolenko.s@domain.com is_uzh@domain.ltd
#doveadm search INBOX from tss@iki.fi <...id-1> <...id-2> ........ <...id-n> Will return just unique ids for current mailbox. Maybe also few headers/flags etc.
#doveadm fetch <...id-2> all Print full message for id, gotten from doveadm searc.
#doveadm fetch <...id-2> hrd.from hdr.subject Print corresponding header values.
Exim also have -Mvl option - which print log lines for current id. It will be nice if:
#doveadm log <id> Found all service records for message and print them to terminal.
With above scheme you don't need to construct separator -