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: t...@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 t...@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 <mykolenk...@domain.com> is_...@domain.ltd #doveadm search INBOX from t...@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 - <id...> will be enough and doveadm next wont be necessary.