[imapfilter-devel] Error: attempt to index field 'INBOX'

[Lefteris Chatzimparmpas]

On Sat, Oct 20, 2007 at 09:57:39PM -0300, Alejandro Jakubi wrote:
> David,
> 
> > Imapfilter uses LUA, which is a quite featureful language.  Anything
> > that imapfilter can't do, you can write in LUA.  If you don't like
> > the
> 
> Yes, googling a bit I have got that impression. But, if I have to
> choose, I would prefer right now an automatization of the mail
> processing tasks (those that I do currently via Pine filter rules),
> even if partial (because "recipes" are not readily available to
> implement everything). Later on I will go into learning LUA for adding
> what is left.

I believe that one can do most common filtering tasks without having to
learn Lua.  Lua is there if someone was to customize filtering or extend
imapfilter.  In your case where you want this kind of behaviour for
keeping deleted messages in some folders, etc. or with logging
information that you find useful... I would not call this "common
filtering", and it's cases like these that Lua becomes so useful.

And that's why imapfilter today embeds Lua, because otherwise I would
have to write a giant program with hundreds of options and operators, in
order to fit every user's needs...

> > messages you'd like to see.  If you don't know how to get
> > information such as the current date and time, you should go do some
> > reading about LUA, as this is really beyond the scope of imapfilter.
> 
> No, currently I do not know. It would be wonderful a pointer to an
> explanation on that.

You can print current date/time like this:

  print(os.date())

You have to read some documentation if you really want to do anything
apart of what is described in the imapfilter_config(5) man page:

  http://www.lua.org/manual/5.1/
  http://www.lua.org/pil/
  http://lua-users.org/wiki/LuaTutorial

> > I believe that the -l flag redirects the output that any print()
> > statements would produce, to the specified file.  Because
> > imapfilter's messages are just regular print() statements, just like
> > your own script
> 
> My first problem here is that I do not see documented what exactly
> this print() command does and what are its parameters and options. Ie
> I see it "used" in the man pages but not "explained". Perhaps I am
> missing something obvious.

The print() command is actually a Lua function, and it just prints
something like a variable, or the result from a function call, etc. to
the standard output.

You're right that it isn't explained in the man page, that's why it
isn't used in the 2.x versions man page, but it's only used in the
examples for the more "advanced" fetch*() stuff.

Also, the -l option just prints any errors (mostly network errors) to
the log file.  If you want to log every action you can do it with a hack
like this; say you want to save the date and some information on what
happened:

  pipe_to('cat >> ~/LOG', os.date() .. '  starting to filter')
  results = match(myaccount, 'INBOX', myfilter)
  move(myaccount, 'INBOX', myaccount, 'spam', results)
  pipe_to('cat >> ~/LOG', os.date() .. '  ' .. #results .. ' moved to spam')

Where .. means concatenate the two strings, and #results is the number
of messages that matched the filter (they were first stored in the
"results" variable).

So the above would append something like this in the file ~/LOG:

  Sun Oct 21 10:42:42 2007  starting to filter
  Sun Oct 21 10:42:43 2007  5 moved to spam


(Actually, Lua has functions to open a file and write to it as much as
you want and then close the file, but as I said the above is just a
hack...)

> > Ah, you have hit upon a common misconception.  There is no such
> > thing as one process "holding" a folder, in IMAP.  IMAP is a shared
> > resource, and therefore you can have multiple processes all
> > connected to the same folder at the same time.  They will not be
> > aware of each other's connections, and they cannot prevent each
> > other from making changes to the folder.  This can lead to some
> > timing bugs!  If you are going to have multiple IMAP clients
> > connected at once, you should keep this in mind when writing your
> > scripts.
> 
> It seems to me that this is rather an issue of wording. Not being an
> expert in IMAP parlance I have put quotes to "holding" as a way to
> convey the idea, betting that it was not the proper technical term.
> But the kind of problems that you describe seems to include the one
> that prompted my question:
> 
> When Pine has the remote INBOX open and imapfilter executes, accessing
> also to this INBOX, Pine produces this error message:
> 
> "[MAIL FOLDER INBOX CLOSED DUE TO ACCESS ERROR]"
> 
> and I have to reopen the remote INBOX.
> 
> In fact the system manager has warned me about this problem of using
> imapfilter, by stating that Pine requires "exclusive access" to the
> INBOX.  I have not checked the documentation of Pine about this
> subject yet.
> 
> So, as Pine "does not like" to share the resource, what about
> imapfilter?

David is right about simultaneous access to IMAP mailboxes, and
imapfilter currently doesn't care if you are browsing your mail with
another IMAP user agent...

> Nevertheles, in automatic mode, I plan to set imapfilter so that it
> filters a few times a day, so that the probability of collision would
> be rather small.
> 
> > Hmm, my man page tells me that this option now defaults to "true",
> > but this was not always the case.  Best to be sure about it rather
> > than make assumptions.
> 
> Do you mean version 2.x default?

It's been enabled since version 1.0.1 and onwards.

> Is there a way to query the value of all the options?

Yes, in the man page, in the OPTIONS section, in the description of each
option, it is specified what the default value for that option is.

> > Are you a member of this mailing list?  I am not sure if I should
> > simply reply to the list, or continue to CC you on these replies.
> 
> I am member of this list (I beleived that I could not post otherwise).
> But I would very grateful if you could continue CC to my address on
> your replies because the messages via the list server arrive here
> rather corrupted (in formating and with missing spaces between some
> words).

Does anyone else has this problem with the missing spaces or missing
line breaks?